Thread: 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/