Skip site navigation (1) Skip section navigation (2)

Re: Installation layout is still hazardous for shared prefixes

From: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Installation layout is still hazardous for shared prefixes
Date: 2000-09-28 16:44:54
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)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
> 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

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2000-09-29 01:31:40
Subject: Bizarre behavior of default access permissions
Previous:From: Jerome RaupachDate: 2000-09-28 16:30:24
Subject: pgaccess

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group