On Fri, May 19, 2023 at 05:34:56AM +0200, Guillem Jover wrote: > > The proposal is to treat this as a flag day, where the toolchain (in this > > case, dpkg-buildflags) changes, then we upload the affected libraries in a > > short period of time, then once they're built and through new we rebuild the > > reverse-dependencies. This is basically the same approach as was used for > > past ABI transitions (ldbl, c102, c2) with the only difference here that the > > change triggering the flag day would be in dpkg rather than gcc(-defaults).
> > There could be some misbuilt binaries in unstable if the maintainer uploads > > them after dpkg is uploaded, but before the libraries are built. If we > > uploaded all of the library packages to set DEB_BUILD_MAINT_OPTIONS = > > feature=+time64 we would avoid this race, but it would mean more > > non-scriptable changes to debian/rules which I would rather avoid, and this > > didn't prove necessary in past transitions; the impact of any misbuilt > > binaries would be short-lived as they would be replaced ASAP with binNMUs. > Given the potential amount of libraries involved that would need an > upload and the chokepoint in NEW, to me this seems like a big window > of opportunity for unstable users that might not be following along > to get a broken system (I mean yes «unstable» and all that, but if it > can be avoided?). Some options that I can see here: - Do the NEW processing in experimental first. In order to avoid additional per-source changes that should be cleaned up later, if we go that route I suggest doing it with an intentionally-incorrect ABI (i.e.: no versioned build-dep on dpkg and no manual enabling with DEB_BUILD_MAINT_OPTIONS). - Get a committment from the ftp team to prioritize binary NEW review for this transition (and without blocking on unrelated source issues, such as buggy debian/copyright...) so that these can all be accepted in a fairly narrow window > Enabling time64 explicitly is what also had first come to my mind, > which does not seem too onerous if all the debhelper override > disappears? :) Then NEW processing could be done in one go to let the > flood gates open at a specific coordinated date and time range (or > staged via NEW into experimental, then mass uploaded to unstable to > reduce the pressure on the ftpmaster(s) having to approve those), at > which point dpkg could also be uploaded with the default switched. The difference in my view is that the changes to handle Provides: are something that should persist in the packaging (until the next soname change, at which point it's easy to handle as part of the overall renaming), whereas explicit changes to set DEB_BUILD_OPTIONS to the future default are something that ideally would be dropped immediately after dpkg-buildflags is updated, and could (though unlikely) be a source of bugs later. I'd prefer to avoid any transition plan which means I should be NMUing all of the affected library packages twice. > Another option, perhaps, could be to flip the defaults, but then block > uploads for affected packages using > <https://ftp-master.debian.org/transitions.yaml>, which I think the > release team controls? I wasn't familiar with this interface, but it sounds like a good option - I can easily provide the list of source packages to populate it with. > But, if people in general are not bothered about this transitory > breakage, and say, an announcement is considered enough, then sure > I guess. > If the other concern is that this would make Ubuntu's life harder due > having chosen to keep i386 as such compat arch, I don't see why the > Ubuntu vendor code in dpkg could not disable the switch for i386 there. We would certainly do this in Ubuntu no matter what decision Debian takes. I am advocating it in Debian because I think it is the right thing for Debian to do as well. Either way, we will need to come to some sort of decision about what to do on i386 before we can move forward. How should we reach that decision? Are you persuaded by the arguments presented in this thread? > Hmm, rechecking the script, I think we'd want to at least > unconditionally add the Breaks and Replaces (no need for substvars > then), otherwise we'd get upgrade errors? > That would leave only the Provides as potentially conditional… You're absolutely right, thanks for catching this! Fixed in git. > > And btw, given the analysis that there are likely < 100 shared libraries > > overall whose ABI changes when enabling LFS, this might be a change we want > > to consider in the trixie cycle as well - just preferably not bundled with > > the time_t transition at the same time, as that would just cause more delays > > for testing migration vs splitting the two transitions. > If the plan is to go with a flag day by switching the default for > time64, then I don't see how the LFS change can be decoupled, as that > automatically will also forcibly enable LFS globally on glibc arches. > I've also in general been worried about automatically enabling LFS w/o > someone looking into each package, given the greater potential for > data loss. :/ I think in the case of LFS-sensitive libraries that aren't part of the dependency graph of packages affected by the time_t change, it's easy enough to patch them to not turn on the LFS flag and avoid a transition. You raise a valid concern about data loss. However, I fail to see any way that we can effectively mitigate this in advance - either now or by delaying the time_t transition. I don't see any way to avoid this via automated source analysis, so the only option (given that we can't avoid the time_t transition forever) is to rebuild and then find out what breaks, which I think is best done at the beginning of a release cycle - do you agree? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
