Re: Installation layout is still hazardous for shared prefixes - Mailing list pgsql-hackers

Tom Lane writes:

> > In the Debian package, I have put the administrator programs in
> > /usr/lib/postgresql/bin.  The postgres user has that directory in its path
> > so that all works properly.  Since root cannot run these, I don't think it
> > appropriate to put them in /usr/sbin.

That's okay as far as Debian goes, because users do not *ever* have to run
initdb, postmaster, etc. because that's done by the package tool and/or
the rc.* stuff, but for a PostgreSQL source distribution (which is what
we're talking about here, binary packagers can always make their own
arrangements) initdb and postmaster do get run by the user so they have to
be in some kind of obvious place.

> choice of a "traditional" setup (both user and admin exes go into
> a single directory, eg /usr/local/pgsql/bin) or a "shared" setup
> (user exes to a shared dir like /usr/local/bin, admin exes still go
> to a private dir like /usr/local/pgsql/bin).

Um, now that would go against the "meta" file system standard that
Autoconf gives us, and I think it's very important to adhere by that
because users expect a configure script to behave in certain ways.

An installation directory looks like PREFIX/SUBTREE/OPT-PRIVATE, where
prefix would be /usr/local/pgsql or /usr/local, subtree is bin, man,
include, etc., and OPT-PRIVATE would be "postgresql".  But you can only
have one prefix, if it's /usr/local then you can't use /usr/local/pgsql
for some other part.

What we could compatibly do is

/usr/local/bin/psql
/usr/local/sbin/initdb

or 

/usr/local/bin/psql
/usr/local/sbin/postgresql/initdb

but the latter is going to be pretty annoying because I've never seen
somebody make subdirectories in bin or sbin.

> Offhand I'd make the division be user:
> 
> createdb dropdb ecpg pg-config pgaccess pgtclsh pgtksh psql
> 
> and admin:
> 
> createlang createuser droplang dropuser initdb initlocation ipcclean
> pg_ctl pg_dump pg_dumpall pg_id pg_passwd pg_restore pg_upgrade postgres
> postmaster vacuumdb

Hmm, I'd rather see createuser, dropuser, vacuumdb, pg_dump, pg_restore in
the first category because that's the client/server split -- the second
category only needs to be installed on the server, the first on clients
and servers.  That might be more useful in more ways and does not make too
many presumptions about usage pattern.

> This would keep createuser/dropuser out of the shared bin directory,
> which certainly seem like the names most likely to cause conflicts.

I'm not so concerned about that anymore, considering that RPM and Debian
are not concerned.  Hiding away executables is probably not the terminally
elegant plan, because users will put them in their PATH anyway before
long.  If someone else can show some other package having a createuser
program, then we need to act, but probably rather by renaming ours.


> Note that it'd be a real bad idea to abandon the option of the
> "traditional" install-tree configuration.  For people like me, with
> three or four versions of Postgres hanging around on the same machine,
> it's critical to be able to install everything into a single private
> directory tree.

That's definitely not going to happen of course.  To make clear what I
want, it's this:

--prefix=/usr/local/pgsql (default)

/usr/local/pgsql/bin/psql ...
/usr/local/pgsql/lib/libpq.a ...
/usr/local/pgsql/include/libpq-fe.h ...
/usr/local/pgsql/share/template1.bki ...

--prefix=/usr/local    !~ /(postgres)|(pgsql)/

/usr/local/bin/psql ...
/usr/local/lib/libpq.a ...
/usr/local/include/postgresql/libpq-fe.h ...
/usr/local/share/postgresql/template1.bki ...

Whether or not we want to have a separate sbin tree is independent of
that, but let's not invent a completely new file system standard for that.


-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/