Hi Helmut, On Wed, May 17, 2023 at 08:31:13AM +0200, Helmut Grohne wrote: > > 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? Yes, those are the categories in question. The 500-600 library packages expose time_t as part of their ABI; the other packages are those that build-depend on those libraries and therefore will need no-change rebuilds to remain compatible. > 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. Packages that have opted in to 64-bit time_t upstream without it being set in dpkg-buildflags are de facto out of scope for this transition. > > === 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. Thanks, good to know this is in progress. Yes, this would need to be enabled by default for the migration. > > * … 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. Sure, that's fine, but those would necessarily be taken case-by-case and don't argue for -D_TIME_BITS=64 by default on i386, since that would extensively break library ABIs depended on by legacy software. > 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. Still, should be handled case-by-case? > Then we have maintainers (such as Russ, but I also vaguely remember other > maintainers) who want to bump soname to unconditionally enable time64. Well, that's their prerogative, and presumably as upstream they know whether the library is of relevance to legacy i386 binaries. The good news is, since it is an upstream SONAME change, if there IS a need to provide the old ABI on i386, this could be done as a separate source package shipping the old binary package name. In which case, the packaging is still simplified overall if i386 does not set -D_TIME_BITS=64 by default. > 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? As the person who was responsible for killing off i386 in Ubuntu as a host architecture, I may not be the best person to ask about a mess that only occurs from continuing to use i386 as a host architecture in Debian, unless you want the same answer ;) In practice though, I don't think we're going to see a huge amount of work from upstreams to enable 64-bit time_t. coreutils and tar are software whose core functionality deals with files and their timestamps; there's very little other software that falls in this category, and of the other software that does, I expect there to be very VERY little software with significant library dependencies. So in effect, my position would be "wait and see, and deal with complexities as they occur". > 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 such cases, yes, I agree that would be the sensible solution. I haven't done any analysis yet to see how many packages would be in this set. https://people.canonical.com/~vorlon/armhf-time_t/abi-breaks and https://people.canonical.com/~vorlon/armhf-time_t/lfs-sensitive would be the starting point, it would at least be easy to check for packages with direct build-dependencies on -dev packages in both sets. > > * 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 such a case the lower-level library should opt in to lfs and have a package name change as well. Up to this point I've casually assumed there weren't any such packages, but this can also be detected via static analysis of the archive. > > * 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? This sounds like a substantial amount of work (and computing resources, to enable this to "continuously" check) and I don't think I understand how it would help the transition, if all of the library transitions are being coordinated centrally. Could you elaborate? -- 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
