Installation layout is still hazardous for shared prefixes

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(at)gmx(dot)net http://yi.org/peter-e/