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: > > * Update dpkg-buildflags to emit -D_FILE_OFFSET_BITS=64 and -D_TIME_BITS=64 > > by default on 32-bit archs. (Note that this enables LFS support, because > > glibc’s 64-bit time_t implementation is only available with LFS also > > turned on, to avoid a combinatorial explosion of entry points.) > As has been mentioned, there's future=+time64 support in dpkg git HEAD > targeted at 1.22.0. This gets automatically disabled on ports where > time_t is known to be 64-bits (even if the port is 32-bits). When time64 > is set it does indeed force future=+lfs. (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'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. > > * … 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. 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. > > * For a small number of packages (~80) whose ABI is not sensitive to time_t > > but IS sensitive to LFS, along with their reverse-dependencies, filter out > > the above buildflags with DEB_BUILD_MAINT_OPTIONS=future=-lfs[1]. > > Maintainers may choose to introduce an ABI transition for LFS, but as this > > is not required for time_t, we should not force it as part of *this* > > transition. If there is a package that depends on both a time_t-sensitive > > library and an LFS-sensitive but time_t-insensitive library, however, then > > the LFS library will need to transition. > Hmm, I'm not sure whether I'm not understanding this point. Perhaps it > is assuming that future=-lfs will strip the LFS options from the > emitted flags? (If so that only disables the feature, but does no > stripping). Also as mentioned above when the +time64 feature is enabled > an -lfs would not be effective at all anyway, and should not! Because if > the time64 flags are emitted glibc will error out if the LFS ones are > not set. (See <features-time64.h>.) > So perhaps this means to say that in these cases we'd use: > DEB_BUILD_MAINT_OPTIONS=future=-time64 > ? Yes, my expectation was that future=-lfs would remove the LFS and time_t flags from the output (the latter, because time64 depends on lfs). But I'm not wedded to this particular interface! My only intent is that there be a simple, short interface for disabling time64+lfs when needed. (I do think that continuing to use 'future' as the canonical category for these flags is wrong and confusing, given that we're talking about them no longer being 'future' but enabled by default.) > > * 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. > 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? > > [1] Seeing that the future is now, maybe we want to consider changing the > > canonical name for this from future=-lfs to abi=-lfs? Bikeshed at will! > Well, we are still not done with LFS, and I'm not seeing the end of that, > so it seemed appropriate at the time, and it kind of still does. :) The > «abi» name seems nice in that it conveys more clearly than «future» that > this can break the ABI (although not necessarily so), but in this case > it's probably better to err on the scarier meaning. So I'll check what > it would take to introduce an alias for that and ponder about it as > there's of course the danger of added confusion. But thanks for the > suggestion! Thanks! 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. -- 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/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: PGP signature