[postgis-devel] liblwgeom versioning

Greg Troxel gdt at ir.bbn.com
Thu Oct 8 05:53:37 PDT 2015


(I have not read all the previous discussion, but am jumping in as the
packager for postgis in pkgsrc.  As far as I can tell I have pretty much
the same concerns as the Debian folks.)

Sandro Santilli <strk at keybit.net> writes:

> The SONAME of liblwgeom will still include Major and Minor PostGIS
> release version, so we'll be able to keep numebers low, enough that
> for 2.3.0 we might start back from 1:0:0 (not done in 2.2.0 because
> we started already with an interface higher than 1).

I don't follow this.  do you mean liblwgeom22.so.x.y?  If so, that
sounds fine.  If you mean that liblwgeom.so.2.2 is forced because of 2,
that sounds wrong.  so versions should increment on ABI breaks, new
functions in the ABI, and other changes, respectively.  They should not
change for other reasons.  so major version (first number) changes cause
work for packaging systems, and if there is an ABI break, that's
unavoidable.  But if there is no ABI break, it's just needless churn.

> I'm not sure it's safe to use 3:0:0 given PostGIS-2.2.0 shipped
> with a liblwgeom of 4:2:0 (decrementing current?).
> The resulting SONAME on Linux is "liblwgeom-2.2.so.3" whereas it
> was "liblwgeom-2.2.so.2" for PostGIS-2.2.0, but I don't know if
> on other systems there could be a different outcome (Bas?).

Ah, now I get it.  You are talking about having liblwgeom-X.Y.so for
postgis X.Y.  That will result in an ABI break on update to postgis 2.3
for anything that actually depends on liblwgeom.  There will presumably
not be that many, so that's probably ok.

I have trouble getting my head around the way that libtool wants sonames
to be specified.  THe mechanism is probably to accomodate other than
elf.   So I think it's helfpul to talk about the ELF versions and then
reverse engineer the libtool codes.

> I believe this is a good compromise between liblwgeom independence
> and easy of maintainance in PostGIS.

It seems reasonable.

  Do you expect there to be an ABI break in liblwgeom in every postgis
  major (e.g. 2.2 to 2.3) release?

  Do you expect postgis packages to include liblwgeom?  Or do you expect
  there to be a separate liblwgeom?  If the latter, there should be an
  easy way (configure flags, or separate directory in the tarball) to
  build just liblwgeom, and then to expect the postgis build to look for
  an use an installed liblwgeom.  Basically my point is either that it's
  part of postgis or it isn't (either is fine), and there is no middle
  ground without a lot of special-case pain.

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


More information about the postgis-devel mailing list