[geos-devel] [postgis-devel] GEOS C++ API deprecated?

[Greg Troxel]

I realize this is basically over now, but as someone who feels like a
bit of an instigator, a few comments.

Sebastiaan Couwenberg <sebastic at xs4all.nl> writes:

> On 10/01/2017 10:05 PM, Mateusz Loskot wrote:
>> On 1 October 2017 at 21:47, Sebastiaan Couwenberg <sebastic at xs4all.nl> wrote:
>>> On 10/01/2017 09:33 PM, Mateusz Loskot wrote:

>> Just stop accepting such GEOS-based software for packaging
>> and keep nagging authors of such projects to switch to GEOS C API,
>> but do not delegate your problem to GEOS.

Mateusz,

I really do not understand your view.  One one hand you seem very
against labeling the C++ API deprecated.  But on the other hand you say
that packagers should consider any package that uses the C++ API
sufficiently broken or wrong that it should be rejected from the
packaging system.

To me, either it's ok to use, or it's not really ok to use.

> The projects in question have been nagged, but that doesn't solve the
> issue. It did cause the libosmium & osm2pgsql authors to drop support
> for GEOS. It did not convince the OSSIM developers to switch to the C API.

all,

As a packager, multiple goals have to be satisfied at once.  The main
one is that with minimal duplicated copies, all the packages have to
build.  Another is that packages do not have included source copies of
other packages, because that slows down patching for vulnerabilities.

Overall, this leads to API stability being important, and that really
isn't about packaging.  The fact that we are talking about a C++ API is
not the point; the basic issue is that an API changed in a way that a
depending program failed to build, and it was not trivial to fix.  Then
that depending program did not quickly issue a release that worked with
the new API.  There was no new major release, and no patch release of
the previous version with an adaptation for the new API.  This shouldn't
be read as a criticism of osm2pgsql; it's a reflection of limited time
budgets and the fact that API breaks really do have a cost.

Packages change APIs (by removing functions) all the time.  But usually
they mark them deprecated and have a new way that's relatively easy to
adapt to, and depending packages mostly adapt and can build with either
for a time.

So I had to essentially decide:

  1) do I update geos and break osm2pgsql, or

  2) do I leave geos and let osm2pgsql still work, at the expense of
  other packages having to use old geos, or

  3) do I reimport the geos package as geos35 and namespace it to allow
  simultaneous installation with the 3.6 version, and have some way for
  osm2pgsql to link against the 3.5 version instead.

I decided (3) was too much work, absent someone paying for labor hours.
(1) did not seem reasonable for the first few months.  After most of a
year (2) did not seem reasonable any longer.  So to decide between 1 and
2, the question arises:

  which of these packages is out of line?

which leads me to ask

   Is it a geos bug that the C++ API changes in ways that break programs
   that use it?

   Is it a bug for other programs to use the C++ API at all?

   Is it a bug in osm2pgsql that a new version did not appear within 3
   months, such that the new osm2pgsql works with the new version of
   geos (perhaps by not calling it at all)?

and hence to poke geos to declare its norms.

We didn't really resolve this -- only deciding not to drop the C++ API.
But as I read the comments, with my own spin, it's generally:

  programs shouldn't really use the C++ API.  But if they do, they have
  to cope with changes, because we aren't making stability guarantees.
  So packagers should feel free to update geos to a release with an
  API-breaking change after a few months, and if any depending package
  breaks, it's their fault because they should have had a new release
  that can use the new API.

> Not accepting such software for packaging is a disservice to our users
> and hence undesirable. Packages are part of a larger ecosystem which is
> affected by removals down the tree, e.g. the removal of OSSIM causes the
> removal of OTB.

Agreed.  It's all about what best serves the users of the packaging system.

>> It is not GEOS problem that someone uses GEOS C++ API.
>> GEOS is C/C++ library.

It is a problem to have APIs that are not stable, regardless of
language.  Others, once they realize this, will try not to use APIs at
all :-)


[ notion of not installing C++ API by default ]

I don't like this at all.  It doesn't address the real issue -- other
packages can still say they need to use the C++ API.  And it just makes
more packages -- one with the C API, and then a 2nd one that adds the
C++ API -- for no real progress.


Note that in all of this I haven't talked about ABI compatibility, only
API.  ABI is much less of a big deal; libraries bump their shlib major
number relatively often.  It does mean that all packages that depend on
the ABI-changed package have to be recompiled, but that's far easier
than having to be rewritten, and it's a fairly normal occurence in
packaging.

Greg
-------------- 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/geos-devel/attachments/20171003/5570c512/attachment-0001.sig>