Peter Eisentraut wrote:
> Projects that are as organized, professional, and value-adding as yours is
> can surely stand on their own. I compare this to the recently released
> OpenFTS. If we start including projects of this size we'd explode in size
> and maintenance overhead.
Fair enough... perhaps we should turn then to some kind of discussion on
packaging standards for postgresql extensions?
- 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.
- Compile our own RPM you say? Yes and no. We could provide a SRPM, but
then we have the same problem: absent a complete postgresql source tree,
we cannot compile. And even if we *do* provide our own RPM...
- 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?
In order to provide a rational RPM source package I ended up having to
provide a complete SRPM of postgresql with the postgis stuff bundled in.
You must build the whole package in order to get the postgis component.
The issue of the extensions dependance on the core is pretty important.
-- __ / | Paul Ramsey | Refractions Research | Email: pramsey@refractions.net | Phone: (250)
885-0632 \_