Bug#756867: transition: gdal
On 06/12/2015 12:26 AM, Emilio Pozuelo Monfort wrote:
> 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.
Rebuilding all affected packages should take care of that.
Isn't the point of a transition to coordinate the upload of the new
library so that the old packages can be rebuilt with it soon after?
The time between the upload of the new library and the rebuild of the
old packages should be minimal, leaving only a short window in which the
old packages may be broken.
> 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?
I don't think it's worth the effort to rebuild all rdepds twice, if
we're going to rebuild them we should just do it for 1.11.
While I'm not entirely happy being unable to mark all affected packages
as good in the tracker, I don't consider it a sufficient problem to add
the alternative dependency to gdal 1.10.1 too.
If there will be a GDAL 1.11.3 after we get 1.11.2 in unstable and
before GDAL 2.0, we can limit the affected packages to those depending
on libgdal.so.1-1.11.2.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Reply to: