[DebianGIS] Re: gdal

[Petter Reinholdtsen <pere@hungry.com>]

[Steve Halasz]
> changed. 1.7.0 -> 2.0.0 would mean the interface had changed. I'd think
> in the latter case that we would go to libgdal2. But I have no
> experience with this or real understanding of what changes the ABI. If
> we do need to change, do we call it libgdal1.9? libgdal2?

ABI changes come from changed struct layouts and reordering/changes in
the function arguments.  It also from from compiler internal stuff
like C++ name mangling, function call conventions and recently with
C++ in debian, STL allocator type.  If any of these changed, the major
soname need to change and the library name need to change too.

So if some function foo(type x) was changed to foo(anothertype y), or
some struct { type x; anothertype y; } was changed to struct { type x;
insertedtype z; anothertype y; }, the memory layout of the ABI changed
and old client programs will fail with the new library.

If only new functions was added, it is ok.  If new struct members were
added to the end of the structs, and these structs are never allocated
on the stack but always come from allocator functions in the library,
the ABI did not change and the library can keep the soname.

There are a lot of corner cases, so this is not the complete picture,
but it does give an idea on the topics affecting the ABI.

So the question you need to find an answer to, is how the library API
changed between the two versions, and if upstream are careful to
change the soname every time changes are done to the API.  The minor
soname version should change every time the public API changes (new
functions, structs), and the major soname version should change every
time an incompatible change is done (changed function arguments,
changed structs etc).  Compiler changes need to be handled by the
distro maintainers, aka us. :)

And if the info from dancer is confusing, I am sure he would welcome
feedback on how to make it less confusing. :)