[postgis-devel] liblwgeom versioning

[Greg Troxel]

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 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 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).

>> 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

>> 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.
>
> Source packages will include liblwgeom, but I expect binary packages to
> ship liblwgeom separately. Starting with 2.2.0 (released tonight)
> there is a way to build liblwgeom only:
>
>   ./configure --without-pgconfig

So after doing that, then 'make' and 'make install' will only build
lwgeom?

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).

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

(The notion of building a single tarball and arranging pieces into
separate binary packages appears in some but not all packaging systems.)

> 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.
-------------- 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/788d8953/attachment.sig>