On Thu, 2023-05-18 at 12:01:40 -0700, Steve Langasek wrote: > On Thu, May 18, 2023 at 03:04:30AM +0200, Guillem Jover wrote: > > On Tue, 2023-05-16 at 21:04:10 -0700, Steve Langasek wrote: > > > === Technical details === > > > > The proposed implementation of this transition is as follows: > > […] (But I've got locally a few > > commits fixing and improving the logic for some of the ports which > > will push out in a bit.)
(I've pushed out those now.) > > I'm perhaps missing something, but the ordering here seems wrong/odd? > > Enabling this by default globally before the shared libraries affected > > by the ABI have been handled seems to me would mean a mess of ABIs > > in unstable until the entire thing converges? > > 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?). 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. 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? But, if people in general are not bothered about this transitory breakage, and say, an announcement is considered enough, then sure I guess. > > > * … but NOT on i386. Because i386 as an architecture is primarily of > > > interest for running legacy binaries which cannot be rebuilt against a > > > new > > > ABI, changing the ABI on i386 would be counterproductive, as mentioned > > > in > > > https://wiki.debian.org/ReleaseGoals/64bit-time. > > > Like Russ, I'm also dubious about this, and introduces a special case > > and complexity that does not seem warranted TBH. If this was the case it > > would seem to me it would disallow SOVERSION bumps for example, which we > > have never been concerned with. > > I didn't see anything in Russ's email in this thread that implied he was > dubious of this approach? He simply has a library he maintains for which he > believes binary compatibility is uninteresting. Ah, indeed, just reread the specific paragraph now, sorry Russ! :) > FWIW in Ubuntu where we maintain i386 strictly as an architecture for > compatibility with third-party binaries, we have 1034 source packages that > build Arch: i386 debs. Not all of those source packages are shared > libraries, but enough of them are that manually updating them to maintain > ABI compatibility on i386 would be a substantial amount of work. In terms > of overall complexity, I think the scales tip in favor of the toolchain not > defaulting to _TIME_BITS=64 on i386. The problem with obsolete packages is also shared by all other arches, and for those and for local packages the dependency system works for the user and should let them know whether they can upgrade or they would need to remove such packages. For other local FOSS packages they might just be able to rebuild them. Excluding i386 from this transition seems to me will pretty much sentence it, and would also make it rather hard to perform that transition cleanly going forward if people want to keep it alive. And while Debian might eventually remove it from its official ports, we have multiple old ports that are still maintained and used. If the main reason is to support non-free binaries, at least to me that does not seem like a very compelling reason. And people can always use old chroots or similar 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. > > > * In order to not unnecessarily break compatibility with third-party (or > > > obsolete) packages on architectures where the ABI is not actually > > > changing, on 64-bit archs + i386, emit a Provides/Replaces/Breaks of the > > > old library package name. A sample implementation of the necessary > > > packaging changes is at > > > https://salsa.debian.org/vorlon/armhf-time_t/-/blob/main/time-t-me. > > > I appreciate the desire to reduce inflicting these effects on arches > > that are not affected, but I don't _think_ (or do not recall) we have > > ever done this kind of special casing when doing similar ABI changing > > transitions in the past? And while ports have clearly arch-specific > > divergences when it comes to dependencies, it seems to me this would > > create a divide at a very different scale? Say for upgrade paths and > > similar testing. > > You're right, we haven't done this before. I thought it worth doing because > although this is roughly the same order of magnitude of transition as the > others we've done, it is still larger and affects not just C++ but also C > libraries. > > shlibs and symbol versions follow the rename, and binNMUs would happen > across all architectures *specifically* to ensure there's not a difference > in upgrade paths. The only difference would be continued installability of > third-party or obsolete binary packages. 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… > > Personally, I'm not sure I'd be thrilled to add that kind of code to > > packages I maintain. :) > > One suggestion I received out-of-band was to put the debian/rules logic > inside of debhelper instead. Would you find that more palatable? …and if for the Provides this can be hidden behind debhelper, then sure that might be better and less error-prone I guess. But Niels would have to weigh in. > 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. :/ Thanks, Guillem
