Peter Eisentraut wrote:
> The 7.1 RPMs should contain the server side headers somewhere. Earlier
> versions only included a not very well defined subset of them.
Indeed they do (nice!), which brings me to a different question:
1 - I download the tarball
2 - ./configure ; make ; make install
3 - Delete the source tree
I now have a complete working pgsql installation, with all the libs to
run the server, and all the headers to build custom clients, but *not*
enough headers to build server extensions, because postgres.h is
missing. However, if I have an RPM-based installation, I *will* have
the server headers I need. Why do we discriminate against people who
compile from the tarball?
> This is a matter taste, or of the file system standard of the system you
> use. If you use autoconf and thus the GNU layout for your source package
> then the default is going to end up something like
>
> /usr/local/lib/postgis/postgis.so
> /usr/local/share/postgis/install-postgis.sql
>
> For binary distributions you'd fiddly with the configure --xxxdir flags a
> little.
>
> Maybe you had in mind some sort of standard layout under a standard
> directory, such as /usr/lib/postgresql/site-stuff (cf. perl), but this
> sort of a arrangement is a major pain. For instance, it won't allow
> non-root installs.
I am tempted to start moving the postgis release to a completely
independant package (not living in contrib by default), with its own
configure script, etc etc, but until the availability of postgres.h is
resolved that might be ill-advised.
