postgresql83, binaries, and paths?

[Jay Levitt]

Ryan Schmidt wrote:
> On Jul 27, 2008, at 11:46, Jay Levitt wrote:
> 
>> I'm setting up a new Mac for Ruby development, and I tried installing the
>> postgresql83 and postgresql83-server ports.  But I couldn't install 
>> Ruby's
>> postgresql gem.  A little digging turned this up:
>>
>> 1. The postgres ports install the pg_config binary (among others) into
>> /opt/local/lib/postgresql83/bin/pg_config.  However, they don't add that
>> directory to PATH.  Should they?  What's the convention for ports and 
>> paths?
> 
> Ports can't add anything to the PATH. There is no mechanism for this in 
> MacPorts (no portfile syntax to allow this).
> 
>>    Given the nice clean paths.d support in Leopard, I'd think they should
>> use it.
> 
> Not all users have Leopard (or even Mac OS X). Also, we decided against 
> using paths.d for MacPorts base even on Leopard because it adds paths at 
> the end of PATH instead of at the beginning like we want.

All true.  But, that said: If the alternative is no PATH support at all, and 
if a port can create a file in /etc/paths.d (and I assume it can), isn't 
that the lesser of two evils?

>> 2. Why is that ending up in lib, anyway?  A clean build from the 8.3.3
>> source puts those files in /usr/local/pgsql/bin, which makes a little 
>> more
>> sense... I think...
> 
> There are multiple versions of postgresql available in MacPorts which 
> can be installed simultaneously, so they can't all install to the same 
> place.

Sorry, I meant that .../bin makes more sense than .../lib/.../bin.  i.e. I'd 
expect to see those binaries in /opt/local/postgresql83/bin... is there an 
advantage to /opt/local/lib/postgresql83?

>> 3. The port makes a half-hearted attempt to get psql into your path: it
>> creates a link from /opt/local/bin/psql83 to
>> /opt/local/lib/postgresql83/bin/psql.  That seems odd too. If the 
>> philosophy
>> is to make it "just work", nobody's going to be typing "psql83"; 
>> they'll be
>> looking for "psql".  But if the philosophy is that users should be 
>> able to
>> do side-by-side installs and roll their own "psql-select", then why 
>> create
>> the link at all?
> 
> I believe the intention is that users should be able to simultaneously 
> install multiple versions of postgresql. As to rolling your own 
> psql-select, we already have gcc_select and python_select ports; a 
> postgresql_select port could be added if that would be useful.

A reasonable intention.  But then why bother linking psql (and only psql), 
and under a name where nobody's looking for it?

I realize the answer to all these questions may be "because that's the way 
someone wrote it once"; in that case, pretend I'm asking "would a patch to 
change that be welcomed/a good idea/grudgingly accepted/treated as a 
maternal-lineage insult?"