Re: PostGIS spatial extensions

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: PostGIS spatial extensions
Дата
Msg-id Pine.LNX.4.30.0108151802310.677-100000@peter.localdomain
обсуждение исходный текст
Ответ на Re: PostGIS spatial extensions  (Paul Ramsey <pramsey@refractions.net>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Re: To be 7.1.3 or not to be 7.1.3?
Следующее
От: Karel Zak
Дата:
Сообщение: Re: encoding names