[postgis-devel] liblwgeom versioning

[Sandro Santilli]

On Thu, Oct 08, 2015 at 09:23:28AM -0400, Greg Troxel wrote:
> Sandro Santilli <strk at keybit.net> writes:
> > On Thu, Oct 08, 2015 at 08:53:37AM -0400, Greg Troxel wrote:
> >> Sandro Santilli <strk at keybit.net> writes:
>
> > I think it would be very helpful to have access to non-ELF systems
> > to see if the 3:0:0 versioning should be changed to be 5:0:0 instead
> > (coming from 4:2:0)
> 
> I don't think we need non-ELF, just to carefully read the libtool rules
> again, every time (speaking for myself).

I did, and it would suggest me to use 5:0:0 (decrement of CURRENT is
never documented as a possibility). It's just a silly thing that it
annoys me to see a jump from "liblwgeom-2.2.so.2" to "liblwgeom-2.2.so.5"
...  

> >> Do you expect there to be an ABI break in liblwgeom in every postgis
> >> major (e.g. 2.2 to 2.3) release?
> >
> > Not necessarely, but since liblwgeom is shipped with postgis, rather
> > than having its own release cycle, keeping it bound to the PostGIS
> > branch name (Major.Minor) is to reduce headaches...
> 
> How does that reduce headaches?  As I see it, all it does is
> 
>   - (potentially) introduce ABI breaks that are not necessary
>   - propagate the confusion that shlib names should change at releases,
>     while
> 
>   + avoid having to keep track of ABI breaks

Actually keep trac of ABI breaks is still needed, as you saw
in this case we're discussing (broke between 2.2.0 and 2.2.1).

The headaches it removes is the handling of branches.
Consider this scenario (with Major.Minor removed):

 1. PostGIS-2.2.1 is released, shipping liblwgeom.so.3.0.0
 2. PostGIS-2.3.0 is released, shipping liblwgeom.so.3.0.1 
 3. PostGIS-2.2.2 is released, shipping liblwgeom.so.3.0.? 

That is, it would be impossible to assign a version to liblwgeom
in a PostGIS branch without looking of which other branches exist.

Or, in other words, the liblwgeom "branches" would mismatch from
the postgis "branches". This is the headache I'm trying to avoid
here. The only solution would be having a different repository
for liblwgeom (but OSGeo is still not ready with hosting git
repositories and the headaches augments...).

> >   ./configure --without-pgconfig
> 
> So after doing that, then 'make' and 'make install' will only build
> lwgeom?

Yes.

> And if you don't do that, then the postgis build will find an installed
> liblwgeom and link against it (or fail)?   My point is that if these are
> two things, they really should be two things (or should be easily and in
> a supported manner be treatable that way).

PostGIS never looks for an installed liblwgeom, with current
build scripts. It links statically against the version of liblwgeom
shipped togheter with it. This may change in case enough support for
such a move is found (among developers and or sponsors).

> If liblwgeom is going to become its own thing, arguably it should have
> its own tarball and release, even if sychronized.

Agreed. We're just not there yet, for the maintainance cost it has.

> > The special-case _maintainance_ pain so far seems to be relieved by
> > including Major.Minor of PostGIS in the SONAME. I understand there's
> > still some _usage_ pain, but we have to find a balance...
> 
> Agreed, and that's minor compared to the
> is-lwgeom-part-of-postgis-or-not issues, as long as not too many
> beyond-postgis things depend on liblwgeom.

Indeed. A good excercise for those who want a standalone liblwgeom
could be to keep a record of how many users already exist.

--strk;

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html