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