Bug#756867: transition: gdal
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.
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.
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.
>>> 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.
>
> Rebuilding rdeps twice wont do anything (but if you push the rebuild with
> old gdal to stable. I'm not sure release managers will accept) because
> jessie packages won't change.
>
> If I understand the problem correctly, the new version of gdal will
> probably need to have a versionned Breaks to all packages that must
> be upgraded with it. It is not enought that packages in sid are coherent,
> they must also work (or Conflict/Break) with packages in stable.
I definitely don't understand your concern. What is your actual real
world scenario, so I can better understand your point of view?
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.
>> 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.
I'm becoming increasingly disillusioned about getting GDAL 1.11 into
unstable and thereby gaining the spatialite_init_ex() support, the lack
of which is currently causing segfaults because only the deprecated
spatialite_init() method is used.
The gdal 1.11.2 package is Ubuntu from some time already, and they
didn't have these concerns. But that may be inherent to Ubuntu not being
as strict as Debian about these kind of issues.
I'd hate having to wait for GDAL 2.0 and the SONAME bump that should
introduce before getting a newer gdal in unstable.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Reply to: