Bug#756867: transition: gdal

[Sebastiaan Couwenberg <sebastic@xs4all.nl>]

On 08/13/2014 02:41 AM, Julien Cristau wrote:
> On Tue, Aug 12, 2014 at 11:41:57 +0200, Sebastiaan Couwenberg wrote:
> 
>> On 08/12/2014 11:26 AM, Emilio Pozuelo Monfort wrote:
>>> On 02/08/14 20:41, Bas Couwenberg wrote:
>>>> Updating GDAL from 1.10.1 to 1.11.0 involves a SONAME bump from
>>>> libgdal.so.1.17.1 to libgdal.so.1.18.0.
>>>>
>>>> Because the binary package name doesn't change, I don't know how to
>>>> format a Ben file to track this.
>>>
>>> Err. What? Are you bumping the SONAME without renaming the package? Why? Why
>>> isn't the package named after the SONAME as it should be? What am I missing?
>>
>> Sorry about creating such confusion by badly wording the issue.
>>
>> The SONAME doesn't change, it remains at libgdal.so.1, only the library
>> version changes.
>>
>> The package is named libgdal1h to differentiate it from its predecessor
>> libgdal1 after the reintroduction of internal symbols hiding for better
>> compatibility against mixing external geotiff and gdal.
>>
>> Because the libgdal exposes both C and C++ symbols, its reverse
>> dependencies need a rebuild to make sure they continue to work in case
>> they don't only use the stable C API but also the unstable C++ API.
>>
>> Does it make sense to you now?
>>
> It doesn't to me...  You seem to be mixing up API and ABI, so I'm not
> sure what you're saying.

I think I did that before, and I must admit that ABIs are not my area of
expertise.

All I know is that we need to rebuild the reverse dependencies for a new
GDAL version, even if the SONAME doesn't change. libLAS even needed
source changes to support GDAL 1.11.0 (since it uses the unstable C++
interface).

README.source in gdal documents the following:

"
 - the C interface is considered stable, but it adds new functions at
   every new release.
 - the C++ interface is considered unstable and adds/removes/changes
   methods at every new minor/major release. That implies both API/ABI
   changes at every new release, possibly.
 - both C and C++ APIs coexists in the same library with a unique
   SONAME (the C one).
 - the only official API that should be used by all programs is the C
   one. At the moment this is generally respected, so forcing a library
   migration should be considered pointless in general.
"

Since the previous gdal transition was not well coordinated with the
release team, I'd like to prevent an uncoordinated upload to unstable
this time.

Since only binNMUs are required with the updated libLAS in the archive,
maybe a transition is the wrong way to go about this, and instead we
(the Debian GIS team) should upload GDAL 1.11.0 to unstable when we're
ready and request the binNMUs afterward?

> Cheers,
> Julien

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/E88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1