Обсуждение: Installation layout is still hazardous for shared prefixes

I've brought this up before, but maybe if I sell it as a bug someone will
agree. :-)

It would be desirable for several reasons that PostgreSQL can be installed
safely with --prefix=/usr/local, or some other such shared location.  
(One reason:  no PATH, MANPATH, LD_LIBRARY_PATH to set up.)

The main problem is that we'd clutter the include/ subtree hopelessly with
files such as <c.h>, <os.h>, <config.h>, which has a serious chance of
breaking other autoconfiscated packages.  Not to mention the other dozen
or so files that will be spread out evenly.

My proposal is to set includedir=${prefix}/include/postgresql (instead of
${prefix}/include) in such cases where the prefix is shared, i.e., it does
not contain something like "pgsql" already. (precise pattern t.b.d.)  
This is similar to the existing RPM's, and compatible with FHS, GNU fs
std., and BSD hier(7).  Apache and Perl also have a similar behaviour in
their installation process.  Additionally, one can now use `pg-config
--includedir` to find the right include directory anywhere.

Marc objected that he liked "everything in one place".  But doing that is
exactly what's causing the problem here.  Additionally I ask why then the
default is prefix is /usr/local/pgsql in the first place, which is
certainly not in support of that notion.  I think having a cooperative
installation layout should be prioritized.

Secondly, I'd like to do the same thing with the share/ subtree.  That
tree is only read by the PG programs anyway so no one has to know about
it.  It's common practice for every package to have its own tree under
share and not to write into it directly.  That would also help associate a
file like `global.description' to where it belongs.

Finally, the doc tree should also get this treatment.  Otherwise we'd get
files like /usr/local/doc/{admin,tutorial}/index.html, which do not
indicate at all what package they belong to and they could be confused
with documentation of the operating system proper.  Users would only have
to update their bookmarks, but I doubt that installations into shared
prefixes are large scale anyway.

Comments?  Better objections? :-)

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

Peter Eisentraut <peter_e@gmx.net> writes:
> It would be desirable for several reasons that PostgreSQL can be installed
> safely with --prefix=/usr/local, or some other such shared location.  
> ...
> My proposal is to set includedir=${prefix}/include/postgresql (instead of
> ${prefix}/include) in such cases where the prefix is shared, i.e., it does
> not contain something like "pgsql" already. (precise pattern t.b.d.)  

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?

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.  The
scripts (createdb and so forth) don't at the moment, and names like
'createuser' clearly have potential for confusion if they are in non-
PG-specific directories.

I think it would be a real bad idea to put the postmaster and postgres
executables right in /usr/local/bin.  Perhaps it is time to think about
a separate 'sbin' directory for programs that aren't supposed to be
invoked by normal users.  Those two, initdb, initlocation, and ipcclean
could certainly go to sbin, also pg_id, maybe the create/drop scripts
if you feel those are admin-only.  Perhaps using a private sbin directory
could eliminate the issue of needing to rename stuff.

The stuff that's going into lib doesn't look like it'd cause any big
conflicts, and I agree that not having to run ldconfig or equivalent
would eliminate a lot of install headaches.
        regards, tom lane

On Wed, Sep 27, 2000 at 10:53:43AM -0400, Tom Lane wrote:
> I think it would be a real bad idea to put the postmaster and postgres
> executables right in /usr/local/bin.  Perhaps it is time to think about
> a separate 'sbin' directory for programs that aren't supposed to be
> invoked by normal users.  Those two, initdb, initlocation, and ipcclean
> could certainly go to sbin, also pg_id, maybe the create/drop scripts
> if you feel those are admin-only.  Perhaps using a private sbin directory
> could eliminate the issue of needing to rename stuff.

generally there is a /usr/local/sbin or /usr/local/libexec for things like
postgres and postmaster.

at least on freebsd.

if we are gonna go this route, i  would prefer that we not have any "special"
directories for postgres, other than the data directory.

a layout of:

/usr/local/bin
/usr/local/include/pgsql
/usr/local/lib
/usr/local/libexec
/usr/local/pgsql/data or /usr/local/pgsql

the last one could also be /home/pgsql or whatever.

-- 
[ Jim Mercer                 jim@reptiles.org              +1 416 410-5633 ]
[          Reptilian Research -- Longer Life through Colder Blood          ]
[  Don't be fooled by cheap Finnish imitations; BSD is the One True Code.  ]

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/

Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > My proposal is to set includedir=${prefix}/include/postgresql (instead of
> > ${prefix}/include) in such cases where the prefix is shared, i.e., it does
> > not contain something like "pgsql" already. (precise pattern t.b.d.)
> 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?

Peter: Please do this....
> 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.  The
> scripts (createdb and so forth) don't at the moment, and names like
> 'createuser' clearly have potential for confusion if they are in non-
> PG-specific directories.

RedHat includes PostgreSQL, with executables in /usr/bin.  There have
been no namespace collisions as yet, with as many packages as RedHat
ships.
> I think it would be a real bad idea to put the postmaster and postgres
> executables right in /usr/local/bin.  Perhaps it is time to think about
> a separate 'sbin' directory for programs that aren't supposed to be
> invoked by normal users.  Those two, initdb, initlocation, and ipcclean

This is doable, but not really necessary.  However, if this is the
direction things are going..... I can certainly work with it.  In fact,
I may go ahead with 7.1's RPMset and do that, popping those executables
in /usr/sbin -- not a big change, by any means, except to the scripts
that are bundled with the RPM.

A good, usable, shared prefix would make my job much easier.  Great gobs
of code in the spec file would go away as PostgreSQL loses the
'/usr/local/pgsql'-centric thinking and gets more in the step of what is
standard for packaging.  And this would help even on system other than
Linux FHS-compliant distributions.  And it would not cause any problems
for those who still want to use a prefix of /usr/local/pgsql.

Thanks for the thinking, Peter.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen wrote: >Tom Lane wrote: >> To do that without creating problems, we'd have to go back to making >> sure that
allthe programs we install have 'pg'-prefixed names.  The >> scripts (createdb and so forth) don't at the moment, and
nameslike >> 'createuser' clearly have potential for confusion if they are in non- >> PG-specific directories. >
>RedHatincludes PostgreSQL, with executables in /usr/bin.  There have >been no namespace collisions as yet, with as
manypackages as RedHat >ships.
 
The same applies to Debian, with something like 4000 binary packages in
the current development tree.
 >> I think it would be a real bad idea to put the postmaster and postgres >> executables right in /usr/local/bin.
Perhapsit is time to think about >> a separate 'sbin' directory for programs that aren't supposed to be >> invoked by
normalusers.  Those two, initdb, initlocation, and ipcclean > >This is doable, but not really necessary.  However, if
thisis the >direction things are going..... I can certainly work with it.  In fact, >I may go ahead with 7.1's RPMset
anddo that, popping those executables >in /usr/sbin -- not a big change, by any means, except to the scripts >that are
bundledwith the RPM. 
 
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.
 >A good, usable, shared prefix would make my job much easier.  Great gobs >of code in the spec file would go away as
PostgreSQLloses the >'/usr/local/pgsql'-centric thinking and gets more in the step of what is >standard for packaging.
Andthis would help even on system other than >Linux FHS-compliant distributions.  And it would not cause any problems
>forthose who still want to use a prefix of /usr/local/pgsql.
 

Agreed.

-- 
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47  6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
========================================   "Let not your heart be troubled; ye believe in God,      believe also in
me."         John 14:1 
 

"Oliver Elphick" <olly@lfix.co.uk> writes:
>> Tom Lane wrote:
>>> I think it would be a real bad idea to put the postmaster and postgres
>>> executables right in /usr/local/bin.  Perhaps it is time to think about
>>> a separate 'sbin' directory for programs that aren't supposed to be
>>> invoked by normal users.  Those two, initdb, initlocation, and ipcclean 
> 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 seems like a good compromise to me.  From a more general
perspective I guess that install would see it as two separate target
directories for executables, which I suppose we'd describe as "user"
and "dbadmin" bin directories.  When installing one should have a
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).

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

(Not sure about pg_dump/pg_dumpall/pg_restore; are these of any
significant use to non-superusers?)  This would keep createuser/dropuser
out of the shared bin directory, which certainly seem like the names
most likely to cause conflicts.

The man pages probably need to adopt the same division as the exes,
ie some to /usr/local/man and some to /usr/local/pgsql/man.

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.

Comments?
        regards, tom lane

Tom Lane wrote:

[useful an complete discussion of sbin-style programs and their place
snipped]

> (Not sure about pg_dump/pg_dumpall/pg_restore; are these of any
> significant use to non-superusers?)  This would keep createuser/dropuser
> out of the shared bin directory, which certainly seem like the names
> most likely to cause conflicts.

pg_dump, yes, as a user might want to dump his own database.
> The man pages probably need to adopt the same division as the exes,
> ie some to /usr/local/man and some to /usr/local/pgsql/man.

Currently, since there is no collision in the executables there have
been no collisions in the man pages.  But, I had a radical idea about
the man pages -- why not package a 'man database' as a dump, let someone
restore that dump into a database, then you can use SQL to access your
man pages.  Of course, you still need docs outside the database, but,
with TOAST, this is possible.

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

No one is advocating removing the 'traditional' packaging from the
options -- least of all me.  Choice and flexibility are my bywords. 
Currently, the PostgreSQL installation is very inflexible WRT the
directories under the installation dir.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

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/

I wrote:

> My proposal is to set includedir=${prefix}/include/postgresql (instead of
> ${prefix}/include) in such cases where the prefix is shared, i.e., it does
> not contain something like "pgsql" already. (precise pattern t.b.d.)  

I think that most people agreed to this step, or at least no one
explicitly disagreed.  Could we move ahead with this?

The default prefix will stay at /usr/local/pgsql so if you are concerned
about createuser, etc. clashing, you don't have to use it.  The decision
about sbin or no sbin can be considered separately.

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