Installation layout is still hazardous for shared prefixes
От | Peter Eisentraut |
---|---|
Тема | Installation layout is still hazardous for shared prefixes |
Дата | |
Msg-id | Pine.LNX.4.21.0009270215510.515-100000@peter обсуждение исходный текст |
Ответы |
Re: Installation layout is still hazardous for shared prefixes
Re: Installation layout is still hazardous for shared prefixes |
Список | pgsql-hackers |
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/
В списке pgsql-hackers по дате отправления: