Bug#756867: transition: gdal
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/;
No packages will be marked as bad, but those that use the C++ symbols
will be marked as good.
Is this acceptable?
I've done a new round of rebuilds for the gdal reverse dependencies, all
build fine with the new version. The rebuilds uncovered an unrelated
FTBFS in osgearth which was fixed last weekend. See:
https://lists.debian.org/debian-gis/2015/05/msg00041.html
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Reply to: