Re: PostGIS spatial extensions - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: PostGIS spatial extensions
Date
Msg-id Pine.LNX.4.30.0108151802310.677-100000@peter.localdomain
Whole thread Raw
In response to Re: PostGIS spatial extensions  (Paul Ramsey <pramsey@refractions.net>)
List pgsql-hackers
Paul Ramsey writes:

> - One of the things we have run up against is that for most linux
> distributions, the postgresql-devel package does not include postgres.h
> in the header package. This is not necessary for client-side programs,
> but it is for server-side extensions. So people cannot compile our
> extension without jettisoning their RPM version of postgresql and moving
> to the tarball.

The 7.1 RPMs should contain the server side headers somewhere.  Earlier
versions only included a not very well defined subset of them.

> - Where should extensions be installed by default? The RPM package has
> some rules, the tarball has some other rules. Should extensions spread
> themselves out over the postgresql tree (libs under lib, docs under doc,
> etc) or should they be self-contained (postgis/lib postgis/doc) under
> some other location?

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.

-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Re: To be 7.1.3 or not to be 7.1.3?
Next
From: Karel Zak
Date:
Subject: Re: encoding names