Re: Installation layout is still hazardous for shared prefixes

Tom Lane writes:

> Hmm, so basically you propose an install setup whereby 'bin' and 'lib'
> files can go directly into /usr/local/bin and /usr/local/lib, but
> everything else still lives in postgres-specific directories?

Yes.

In detail, for those who cry "do it like Debian", we have these categories
of installation directories (not all actually used by PostgreSQL):

bin    - user programs
sbin    - administrator programs
libexec    - programs used only by other programs

lib    - libraries
include    - headers

share    - architecture independent read-only data
etc    - single-host read-only data
com    - architecture independent writeable data
var    - single-host writeable data

doc    - documentation
man    - manual pages

These do not actually have to exist with these names (although they
usually do), but the point is that each directory has a fairly orthogonal
purpose, thus enabling the local installer to easily adopt the layout to
his local convention.

Now the convention is that if you have a lot of files to put into one of
these directories you create a private subdirectory, which is what I'm
proposing here.  However, the bin, sbin, lib, and man directories are
obviously exempted from this convention, because otherwise the
shell/linker/man system won't find the files without the same contortions
we're trying to avoid here.

> To do that without creating problems, we'd have to go back to making
> sure that all the programs we install have 'pg'-prefixed names.

Yeah, that again.  That would be a true incompatibility, though, so it's
more complex.  But let's consider that complementary, not prerequisite to
the issue at hand.

> I think it would be a real bad idea to put the postmaster and postgres
> executables right in /usr/local/bin.

Why?

> Perhaps it is time to think about a separate 'sbin' directory for
> programs that aren't supposed to be invoked by normal users.

Good idea as well, but again a compatibility break that needs to be
thought about.

> Perhaps using a private sbin directory could eliminate the issue of
> needing to rename stuff.

I don't think private sbin directories are conventional.  But again,
that's really a complementary issue.


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