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

Re: Installation layout is still hazardous for shared prefixes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Installation layout is still hazardous for shared prefixes
Date: 2000-09-27 14:53:43
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Peter Eisentraut <peter_e(at)gmx(dot)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

In response to


pgsql-hackers by date

Next:From: Jim MercerDate: 2000-09-27 15:02:06
Subject: Re: Installation layout is still hazardous for shared prefixes
Previous:From: Tom LaneDate: 2000-09-27 14:41:38
Subject: Re: Reimplementing permission checks for rules

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