[postgis-devel] Allowing use of PostGIS EXTENSION w/out raster

[Greg Troxel]

[split reply, and omitting chunks where I have nothing to add]

Sandro Santilli <strk at kbt.io> writes:

>>   how should this be packaged?  Is there one postgis package with two
>>   extensions, or one postgis-noraster and one postgis-raster?  Or is
>>   there a postgis package that doesn't depend on gdal and a
>>   postgis-raster that does?
>
> I think what I'd like to have would be:
>
>    - package postgis_core
>    - package postgis_raster depends on postgis_core
>    - package postgis_topology depends on postgis_core
>    - package postgis_whatever depends on postgis_core
>    - package postgis depends on all of the above
>
> Right now you have a single "postgis" package with everything in it,
> so can as well continue to have that for some time and postpone the
> splitting of packages.

That makes sense.   I think this only works with separate extensions,
rather than files that change content based on enabled/not.

But really the point is about having files in core that are the same
bits regardless of the others, and whether it's a separate extension or
ALTER magic is not necessarily important.   Separate extension feels
cleaner and easier to explain though.

>> If there are to be two packages, then perhaps there should be two
>> distribution tarballs.
>
> I don't understand this statement, Debian already has multiple
> packages from a single tarball, for example:
>     postgis
>     postgis-gui
>     postgis-doc
>     postgresql-9.5-postgis-2.4,
>     postgresql-9.4-postgis-2.4-scripts

Yes, but (AIUI) at build time you have to have the union of the
dependencies installed, and then the resulting files are allocated to
the split packages.  If the model is that building packages is rare, and
that users basically use binary packages, that works, because the fact
that the build machine needed gdal is amortized and nobody really cares.

With pkgsrc, the notion is that it's normal to build from source, and
that there are so many operating systems and CPU architectures that
there really will not be binary packages for all.  So with a
Debian-style split package setup, if someone wanted postgis but not
raster, the system would still force them into building gdal.

One can also have multiple packages built from a distribution tarball
where one builds sub-directories.  For that to be easy, there needs to
be a way to configure --enable just the core, and then after that build
is done, unpack a fresh copy and configure differently and just build
one extension, linking against the installed copy.  Making things behave
like this when they don't natively is basically more work than I want to
do.  So if postgis builds multiple extensions and it's not easy to build
separately, there will probably just be one package that depends on the
union of the dependencies, perhaps with a build-time option to disable
the heavy dependencies (but options and binary packages are basically
not compatible conceptually).  But that's ok; no worse than now for
build and batter at runtime, so progress.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 162 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20171009/e1df213c/attachment.sig>