postgresql83, binaries, and paths?

[Ryan Schmidt]

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.

> 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.

> 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.