[postgis-devel] liblwgeom versioning

[Greg Troxel]

Sandro Santilli <strk at keybit.net> writes:

> On Thu, Oct 08, 2015 at 09:23:28AM -0400, Greg Troxel wrote:
>
> 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"
> ...  

That seems goofy but I can't argue that you are wrong...   It seems
obvious that .so.2 with an ABI change should change to .so.3.

I guess another question is if we are aware of anyone running postgis
on any non-ELF system that has unix-like library versioning.    I am
pretty sure NetBSD is all ELF now (of course it used to be a.out).

All that said, I do not understand windows library versioning at all.


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

I only sort of follow you, but I get it that combining things that
should be separate get to be trouble.

Perhaps it's then a good plan of leaving lwgeom-X.Y.so for now, and
dropping the -X.Y when it becomes a first-class separate package, with
its own tarball, release number, pkgconfig, etc.  Which is the path you
are heading down, I think, eventually.

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

Sounds good; then I could make a liblwgeom package easily.  But until
some other package needs it, I probably won't.

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

I see, so the only real minus is building it twice, which in the grand
scheme of things doesn't matter that much.


Thanks for reading all of this...

(I am building 2.2 on NetBSD, and running into packaging nits about perl
- will send a regression test report later.)
-------------- 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/20151009/c27290f3/attachment.sig>