Bug#756867: transition: gdal
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.
Most affected packages use C++ symbols, only grass, mapserver, ncl,
postgis, vtk, xastir and mapcache didn't use any C++ symbols when I
tested this the first time. Curiously openscenegraph (3.2.0~rc1-5.1) in
unstable didn't use C++ symbols but the 3.2.1 version in experimental
did. See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756867#45
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Reply to: