[postgis-devel] wait till monday for final ?

Stephen Frost sfrost at snowman.net
Thu Oct 8 05:26:29 PDT 2015


* Bas Couwenberg (sebastic at xs4all.nl) wrote:
> On 2015-10-08 12:12, Sandro Santilli wrote:
> >On Thu, Oct 08, 2015 at 11:26:03AM +0200, Bas Couwenberg wrote:
> >>For Debian we'll keep PostGIS 2.2.0 in experimental until this
> >>API/ABI breakage is fixed in 2.2.1 or later.
> >
> >I'm not sure I understand what you mean here.
> >
> >Note that there's been no ABI breakage so far, as 2.2.0 is the
> >very first version that ships a liblwgeom with SONAME
> >"liblwgeom-2.2.so.2"
> >(as any precedent version was the first and only version with its
> >unique SONAME).
> 
> ABI breakages require a transition to rebuild all reverse
> dependencies to use the new library.
> 
> Since another ABI breakage is expected in the next release after
> 2.2.0, it's better to wait for that an not have to transition twice
> in a short time frame.

Meh.  We're talking about unstable here, right?  I agree that it isn't
ideal, but I don't think it's unheard of either.

That said, if 2.2.1 is imminent, then waiting makes sense.

> In Debian we prepare transitions in experimental until we're ready
> to start the transition in unstable from which it will migrate to
> testing for inclusion in the next stable release and from where
> Ubuntu syncs its packages.

You can always prevent it from going into testing pretty easily, if
necessary.

> No, changing the SONAME is required to sanely deal with the ABI
> breakage, so this is fine.

Agreed.

> Based on the previous SONAME discussion I think it's better to make
> liblwgeom into a postgis-only library again, and make it clear that
> other projects should not use it. An unpopular decision but one that
> fits with the postgis development.

I don't believe it's Debian's role to tell projects how to manage their
libraries.  Further, having it as a library makes that functionality
available to other projects and efforts, with is an all-together good
thing (tm).  I've wanted to have that myself in the past and complained
bitterly about the command-line utilities pulling in large static blocks
of code which could and should live as libraries, when I was the DD for
PostGIS.

What would be most helpful here is for folks who are more familiar with
maintaining libraries, dealing with API/ABI breaks, etc, to work with
the PostGIS developers to smooth out the overall process.  I don't
believe there's anything inherently bad with having this capability in a
shared library, but people need to understand the impact that API/ABI
breaks have and how to manage them properly.  A lot of projects have
gone through that growing pain (I remember back to all the issues libdb
had..) and come out better from it, but it'll take a few releases.

From the discussion on this thread, it sounds like the issue is that
more performance testing needs to be done in an automated way, to avoid
these regressions, and a project policy needs to be worked out around
API/ABI changes- generally speaking, I wouldn't expect a point release
to change the ABI for a library, as an example.  That might mean that
some changes have to wait for the next major release, but so be it- we
have that same issue in PG too, as do a lot of projects.  It can be
frustrating at times but it also shows the maturity of the project.

Thanks!

Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20151008/55aab99e/attachment.sig>


More information about the postgis-devel mailing list