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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
