Re: PostGIS spatial extensions

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.