Re: Installation layout is still hazardous for shared prefixes
От | Tom Lane |
---|---|
Тема | Re: Installation layout is still hazardous for shared prefixes |
Дата | |
Msg-id | 6787.970066423@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Installation layout is still hazardous for shared prefixes (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Installation layout is still hazardous for shared prefixes
Re: Installation layout is still hazardous for shared prefixes |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: