[geos-devel] RFC6 - Discourage use of C++ API by requiring a configure switch to install the c++ headers and SDK

[Sebastiaan Couwenberg]

On 10/06/2017 10:28 AM, Robert Coup wrote:
> Hi Bas,
> 
> On 5 October 2017 at 11:01, Bas Couwenberg <sebastic at xs4all.nl> wrote:
> 
>> Yes, Debian distributions will only ever have a single gdal package,
>> Ubuntu by extension will too (because they just copy the packages from
>> Debian) although newer versions are available in the UbuntuGIS PPA (which
>> is a separate repository from the Ubunu ones). The same goes for other
>> packages like geos, spatialite, rasterlite, spatialindex, postgis, etc,
>> only one version will be included in the distribution that all reverse
>> dependencies will use.
>>
>> Multiple versions make security updates more complex because more than one
>> package needs to be patched, and also makes integration of reverse
>> dependencies more complex because they'll need to be adapted for one of the
>> versions.
>>
> 
> Ok, so the restriction is policy-based, not technical. Debian/Ubuntu
> releases won't provide multiple versions of GEOS, but if someone
> builds/runs their own repo then the system will support multiple versions
> (eg. continuing my example, a backport of the libgdal20 package will
> install alongside libgdal1h).

The fun begins when you have libgdal20 in the distribution and build the
latest 2.x yourself. Nobody should be using distributions with libgdal1h
any more.

> Seems fair enough :)
> 
> Followup question (and vaguely asking you to generalise on behalf of all
> distro maintainers) – do you think in the general case distros would take
> the upstream project advice and *not* set `--enable-the-cpp-sdk` in builds,
> and also therefore *not* accept uploads of new packages using the C++ API?
> Debian tends to have a build-with-the-kitchen-sink approach in my
> experience, but there has to be a limit somewhere.
Since I maintain the geos package in Debian and have to coordinate the
transitions when ABIs break, the package will not re-enable the C++
headers. That will cause bugreports for GRASS & OSSIM to switch to the C
API, or their projects will be removed from Debian and by extension from
Ubuntu. GRASS will most likely make the switch shortly thereafter, OSSIM
probably not. The OTB project will have to act to not have their package
removed due to their ossim dependency, and move on with their
ossim-light fork that lacks the problematic GEOS dependency.

I cannot speak for the other distributions, but I expect them to not
enable the configure option unless they have other packages that need
it. E.g. all distributions that also include GRASS and/or OSSIM. The
GRASS dependency on libgeos may just be because they use `geos-config
--libs` instead of `geos-config --clibs`.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1