Bug#756867: transition: gdal
On 06/12/2015 05:12 PM, Vincent Danjean wrote:
> Le 12/06/2015 12:17, Sebastiaan Couwenberg a écrit :
>> On 06/12/2015 07:30 AM, Vincent Danjean wrote:
>>> Le 12/06/2015 01:06, Sebastiaan Couwenberg a écrit :
>>>> On 06/12/2015 12:26 AM, Emilio Pozuelo Monfort wrote:
>>>>> 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.
>>>
>>> This is true only if the new version of gdal cannot be installed with
>>> old (jessie) version packages using it.
>>> I do not known anything about gdal. But remember you cannot assume that
>>> users will upgrade in one row from jessie to stretch/testing/unstable.
>>
>> I don't believe partial upgrades are supported, so this seems a mostly
>> theoretical problem.
>
> They are from stable to next stable. We already had the same discussion
> several times with various software (the last one I remember being R).
>
>> Actual users of gdal and its rdeps will want to be able to use those
>> rdeps so they will be motivated to not do a partial upgrade.
>
> My point is that the dependency system must ensure that packages
> installed together, respecting package dependencies, from two consecutive
> Debian release, work together.
>
>> GDAL 1.11 is the first version that allows tracking of the rdeps that
>> use the C++ symbols, all earlier upgrades didn't care about that. Those
>> relied on the symbols version only for upgrades.
>
> If the dependency system allows to have gdal 1.11 and old rdeps, then
> they must work.
> If old rdeps and gdal 1.11 does not work together, the dependency system
> must reflect that (for example by adding versionned Breaks in new gdal
> against old rdeps).
>
>> I definitely don't understand your concern. What is your actual real
>> world scenario, so I can better understand your point of view?
>
> I hope the previous sentences (and the next one) explains my view.
> If this is not the case, please tell me.
>
>> To my best understanding, distribution upgrades from jessie to stretch
>> will just work, with or without alternative dependency for packages
>> using C++ symbols, as they did before.
>
> You must also ensure that, on a jessie system,
> "apt-get install -t stretch gdal" will not break any other package
> (in particular gdal rdeps) [unless these breaks are declared as Breaks
> or Conflicts or ... so that the "apt-get ..." command takes them into
> account]
Thanks for the clarifications.
I agree that it's best to have the dependencies prevent users doing
foolish things like upgrading only gdal and expecting the rdeps to still
work.
Currently we don't know the versions of the rdeps that will break, so
these cannot be declared in the control file yet. I'm not sure how to
solve this (without adding the alternative dependency in the jessie
version of gdal).
This hasn't been an issue before, so I'm tempted to ignore it. Unless
the Release Team wants this addressed, then we'll need to update gdal in
jessie first.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Reply to: