Hi! 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? > * … 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. > * 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 ? > * 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. Personally, I'm not sure I'd be thrilled to add that kind of code to packages I maintain. :) > [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, Guillem
