[geos-devel] 3.2.0 release ready for download

[Greg Troxel]

strk <strk at keybit.net> writes (reordered)

> Is this too much confusing ?

Yes :-) So here are the results of the build on NetBSD with pkgsrc.  The
build is very default, with the only change being putting @LDFLAGS@ into
geos-config so that rpath works right.  So here are the results:

For 3.1:

-rwxr-xr-x  1 root  wheel  1703998 Dec 15 10:27 libgeos-3.1.0.so
-rw-r--r--  1 root  wheel  3626526 Dec 15 10:27 libgeos.a
-rwxr-xr-x  1 root  wheel      844 Dec 15 10:27 libgeos.la
lrwxr-xr-x  1 root  wheel       16 Dec 15 10:27 libgeos.so -> libgeos-3.1.0.so
-rw-r--r--  1 root  wheel   101126 Dec 15 10:27 libgeos_c.a
-rwxr-xr-x  1 root  wheel      871 Dec 15 10:27 libgeos_c.la
lrwxr-xr-x  1 root  wheel       18 Dec 15 10:27 libgeos_c.so -> libgeos_c.so.1.5.0
lrwxr-xr-x  1 root  wheel       18 Dec 15 10:27 libgeos_c.so.1 -> libgeos_c.so.1.5.0
-rwxr-xr-x  1 root  wheel   103071 Dec 15 10:27 libgeos_c.so.1.5.0

For 3.2:

-rwxr-xr-x  1 root  wheel  1894950 Dec 14 18:29 libgeos-3.2.0.so
-rw-r--r--  1 root  wheel  3884736 Dec 14 18:29 libgeos.a
-rwxr-xr-x  1 root  wheel      844 Dec 14 18:29 libgeos.la
lrwxr-xr-x  1 root  wheel       16 Dec 14 18:29 libgeos.so -> libgeos-3.2.0.so
-rw-r--r--  1 root  wheel   138296 Dec 14 18:29 libgeos_c.a
-rwxr-xr-x  1 root  wheel      871 Dec 14 18:29 libgeos_c.la
lrwxr-xr-x  1 root  wheel       18 Dec 14 18:29 libgeos_c.so -> libgeos_c.so.1.6.0
lrwxr-xr-x  1 root  wheel       18 Dec 14 18:29 libgeos_c.so.1 -> libgeos_c.so.1.6.0
-rwxr-xr-x  1 root  wheel   133825 Dec 14 18:29 libgeos_c.so.1.6.0

> On Mon, Dec 14, 2009 at 06:39:21PM -0500, Greg Troxel wrote:
>
>> The shlib major version changed; probably NEWS should mention that. 
>
> GEOS has 2 shared libraries. 
> The one implementing the C++ API and the one implementing the C API.
>
> While we maintain proper library versioning for the C API, we don't
> for the C++ one, due to the way too wide set of exposed interfaces
> we should look at to figure when ABI was or wasn't broken (and in C++
> land ABI breaks SO easily).

OK, but it would be good to say that c++ shlib version changed in NEWS,
because that is in itself an ABI change, which I realize makes
irrelevant whether the actual ABI of the library changed.

The whole relationship between libgeos and libgeos_c was unintuitive,
but now I figured it out, and I see the c library major version did not
change.

>> (From a packaging point of view, shlib
>> version changes when there aren't actually ABI changes generates work
>> that could be avoided; all depending packages need a version change
>> because they only interoperate with one or the other geos version.)
>
> This is exactly the reason why we incourage use of the C library
> (libgeos_c.so). The C library hard continues to expose a compatible ABI
> to the ABI-incompatible C++ library.
>
> So, while GEOS 3.2.0 *c++* lib is a few steps away from GEOS 3.0.0 *c++* lib,
> any code which linked against the *c* lib in GEOS 3.0.0 will still work
> with the *c* lib of GEOS 3.2.0.

I see; it might be nice to have the C wrapper separately buildable and
then it could easily be in a separate package (via --disable-c++ and
--disable-c, where --disable-c++ builds the c wrapper and expects
libgeos already installed).

>>From a packaging point of view you should likely properly encode
> if a client is dependent on *libgeos* or *libgeos_c* as that makes
> a big difference.

Agreed, probably should but we don't.  It's not just libraries but
programs.  Now, if something depends on 'geos', then it gets a revision
bump if the ABI of the *geos package* changes, which it does if any
shlib or program used by a program (none in this case) changes.
And geos-config seems to be maingly the c++ version (with --libs).

Perhaps two pkg-config files should be installed, for geos and geos_c.

I realize splitting c/c++ is a lot of work for not much gain, but
thought it might be helpful to explain where I'm coming from.
Explaining API and ABI changes in NEWS should be easy (even to say "This
is API compatible with release X" when there are no backwards
incompatibilites) -- that's the information I need to adjust the
packaging control files.

Thanks for the explanations.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/geos-devel/attachments/20091215/8d35d6d2/attachment.bin