Bug#756867: transition: gdal

[Emilio Pozuelo Monfort <pochu@debian.org>]

Hi, and sorry for the late reply.

On 31/05/15 15:59, Sebastiaan Couwenberg wrote:
> On 05/31/2015 03:19 PM, Emilio Pozuelo Monfort wrote:
>> On 26/05/15 23:16, Sebastiaan Couwenberg wrote:
>>> Dear Release Team,
>>>
>>> To move away from the deprecated spatialite_init() method that is
>>> causing issues since the proj 4.9.1 transition (#785091) we need to get
>>> gdal 1.11.2 out of experimental.
>>>
>>> We didn't manage to get it into jessie, so I'd like to restart this
>>> transition for stretch as soon as possible.
>>>
>>> There is still an outstanding question of how to best track the transition.
>>>
>>> On 09/11/2014 10:39 PM, Sebastiaan Couwenberg wrote:
>>>> On 08/13/2014 11:22 PM, Emilio Pozuelo Monfort wrote:
>>>>> On 13/08/14 18:51, Sebastiaan Couwenberg wrote:
>>>>>> On 08/13/2014 06:18 PM, Julien Cristau wrote:
>>>>>>> OK, I'd suggest something like this:
>>>>>>> - add Provides: libgdal.so.1-${version} to libgdal1h (${version} being
>>>>>>>   1.10.1 or 1.11.0)
>>>>>>> - adjust libgdal1h.symbols.* to generate a dep on
>>>>>>>   libgdal.so.1-${version} for all c++ symbols
>>>>>>>
>>>>>>> That way it's clear from the packaging metadata what uses only the
>>>>>>> stable C interface and what uses the unstable C++ one, and we know what
>>>>>>> to rebuild.  Does that seem plausible?
>>>>>>
>>>>>> Thanks for the helpful suggestion, it sounds like a nice solution.
>>>>>
>>>>> Indeed. That sounds somewhat similar to what qtbase-opensource-src does, with
>>>>> the Provides: qtbase-abi-5-3-1 (that change whenever the ABI changes).
>>>>>
>>>>>> I'll have a look at implementing it.
>>>>>
>>>>> You can probably use dependency-templates on the symbols file, adding a
>>>>> libgdal-1.10.1 template and making all the c++ symbols have a dependency on it.
>>>>> See the "Advanced symbols file" on deb-symbols(5).
>>>>
>>>> I've implemented the alternative dependency template in the latest
>>>> revision of gdal 1.11.0, and I've done a rebuild of all rdeps to see
>>>> which of them use C++ symbols.
>>>>
>>>> Most packages use the alternative dependency template. The source
>>>> packages for grass, mapserver, ncl, openscenegraph (3.2.0~rc1-5.1),
>>>> postgis, vtk, xastir and mapcache don't use any C++ symbols.
>>>>
>>>> It's interesting that the openscenegraph version in experimental does
>>>> use some gdal C++ symbols, but the version in unstable does not.
>>>>
>>>> If we want to use this feature to track the GDAL 1.11.0 transition we'll
>>>> need to implement it in GDAL 1.10.1 too and binNMU all the rdeps. The
>>>> ben file for the 1.11.0 transition could then be:
>>>>
>>>>  title = "libgdal1h";
>>>>  is_affected = .depends ~ /libgdal.so.1-1.10.1/;
>>>>  is_good = .depends ~ /libgdal.so.1-1.11.0/;
>>>>  is_bad = .depends ~ /libgdal.so.1-1.10.1/;
>>>>
>>>> But this would exclude vtk6 which uses symbols introduced in 1.11.0 when
>>>> built with it. So I'm not sure if this is the right way forward. Keeping
>>>> all packages build depending on libgdal-dev as affected and not
>>>> explicitly marking the packages that don't use C++ symbols as good may
>>>> be an option.
>>>>
>>>> Would that be acceptable for the Release Team?
>>>
>>> With the above in mind I suggest the following ben configuration:
>>>
>>>  title = "libgdal1h";
>>>  is_affected = .build-depends ~ /libgdal1?-dev/;
>>>  is_good = .depends ~ /libgdal.so.1-1.11.2/;
>>>  is_bad = .depends ~ /libgdal.so.1-1.10.1/;
>>
>> I have created https://release.debian.org/transitions/html/gdal-1.11.html
>>
>>> No packages will be marked as bad, but those that use the C++ symbols
>>> will be marked as good.
>>>
>>> Is this acceptable?
>>
>> So what do you propose here? Should we rebuild only those packages that use any
>> of the C++ symbols? If so, do you have a list?
> 
> Thanks for creating the tracker.
> 
> I suggest to binNMU all affected packages, but only those that use any
> C++ symbols will be mark as good in the tracker leaving the others unknown.

So let's say gdal 1.11 changed the ABI for some C++ symbols. Since the packages
currently in sid don't have strict dependencies on the old ABI, the new library
will be installed with the old packages, causing breakage.

What do you think about that situation? Should we add the dependency magic to
1.10, rebuild everything, and only then update to 1.11? Or do you think that
case isn't a problem?

Cheers,
Emilio