Hi Steve, On Tue, May 16, 2023 at 09:04:10PM -0700, Steve Langasek wrote: > Over on debian-arm@lists, there has been discussion on and off for several > months now about the impending 32-bit timepocalypse. As many of you are > aware, 32-bit time_t runs out of space in 2038; the exact date is now less > than 15 years away. It is not too early to start addressing the question of > 32-bit architecture compatibility, as there are already reports in the wild > of calendar failures for future events on 32-bit archs.
Thanks for not having dropped the ball on this and for the detailed analysis. > Based on the analysis to date, we can say there is a lower bound of ~4900 > source packages which will need to be rebuilt for the transition, and an > upper bound of ~6200. I believe this is a manageable transition, and > propose that we proceed with it at the start of the trixie release cycle. Can we try to distinguish affected packages into those that change their downstream interface (i.e. mostly shared libraries changing ABI) and those that do not (e.g. application packages)? Do I understand correctly that those 500 mentioned earlier are the former category and the these 4900 to 6200 are the latter category? Please bear in mind that packages are already starting to enable time64 support. coreutils is built with time64 for a while already and tar was recently switched to time64 (see #1026204). As such, I think it would be good to treat these categories as more distinct. When in doubt, we should treat a package as breaking its interface though. > === 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.) There already is a pending patch for feature+time64 see #1030159. You are asking to enable this by default effectively. > * … 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. I think this needs a second thought. coreutils and tar already enable time64 on i386 and I expect that more things will. From my point of view, such updates are a good thing and we should not skip them on i386, because they do not affect ABI. It is not as simple as this unfortunately. While coreutils and tar have been simple, other packages will likely depend on their libraries being time64. In such cases, we will be unable to enable time64 unless we also the underlying libraries do so a well. Then we have maintainers (such as Russ, but I also vaguely remember other maintainers) who want to bump soname to unconditionally enable time64. As a result, I expect that i386 would become a wild mixture of time64 and time32. Do you have thoughts on how to deal with the resulting mess? I would also like to point out that there is a third option on the table that nobody seems to be talking about. Instead of changing (breaking) the ABI of libraries, we may also consider adding a time64 ABI to existing libraries. A header can trivially detect whether time64 is being requested by checking the relevant macros and in such cases divert functions affected by time64 to 64bit-aware variants. Thus, a library may become time64-compatible without breaking ABI with non-time64 users. The obvious downside of this is that is quite a lot of effort and is probably infeasible unless upstream cooperates, but I think this should be considered as an option for difficult cases where we have both non-lfs and time64 downstream users in large numbers. Do you agree? > * 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. I note that this may pose problems with intra-library interaction. Say we need to enable time64 on a higher level library and a lower level library does not use time_t, but uses off_t. As such, you'd opt out of lfs on the lower level library, but the upper one uses it with lfs by having enabled time64. How do you intend to deal with such cases? > * 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. This is a nice way to minimize the effects on 64bit architectures. Something that would help with this transition would be a checker-as-a-service kind of thing that indicates: * Is my package affected by time64? * Does my package enable time64? + On i386? * Do time64 changes affect downstream packages? + Which? I understand that answering these questions on a per-package basis is far from trivial. That much is evident from your analysis. I think this is ok. Even if such a service says "unknown" 10% of the time, that'd still be very useful. Do you think you could turn your analysis into a continuous checking service? > [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! I fear this is too late, but you may still be able to avert future=-time64. Helmut
