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 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/557ab1b7.7060...@xs4all.nl
