postgresql83, binaries, and paths?
lists-macports at shopwatch.org
Sun Jul 27 14:20:05 PDT 2008
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
>> 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
> 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
>> 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
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
>> 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
>> 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
More information about the macports-dev