[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#756867: transition: gdal



Control: forwarded -1 https://release.debian.org/transitions/html/gdal-1.11.html

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?

Cheers,
Emilio


Reply to: