On 2022-11-12 11:15 -0800, Paul Eggert wrote: > On 2022-11-12 10:50, Bruno Haible wrote: > > I'm saying > > "tiny" because we are still 15 years away, and new releases of the (not > > many) affected packages are likely to come in the next 1-2 years. > > Not so "tiny", I'm afraid. My department is still running a server with > libraries and executables that are over 17 years old. Nobody disagrees with the idea that 2038 fixes are now fairly urgent if we want to avoid real-world stuff breaking in 15 years time. That has been increasingly clear for the last few years. But the point here is that we need a bit of co-ordination and a plan, particularly for binary distros. This isn't a minor change that should just happen to people because there was an autoconf upgrade. Or at least I don't think it is. My assumption is that if you just turned it on in random packages as they were uploaded, there would be very serious (unacceptably bad) breakage - we need to co-ordinate sets of matching-ABI packages to upgrade together, and the worry is that the matching set is 'most of the distro'. Now, I'm not yet sure if just having autoconf 2.72 will actually break things. AIUI, these changes only apply where LFS (-D_FILE_OFFSET_BITS=64) is turned on, so in Debian at least, where that is not the default on 32bit arches, maybe this is OK. But probably quite a lot of packages already enable LFS so they are suddenly going to get a new ABI if they expose timet anywhere? https://codesearch.debian.net/search?q=AC_SYS_LARGEFILE&perpkg=1 shows 163 pages of hits, and a quick peruse suggsts that AC_SYS_LARGEFILE is used by a lot of packages (as you might expect - this transition has been going on for many years). And just having that macro in configure.(in|ac) will turn 64-bit timet on if you autoreconf with 2.72. Right? We can't embark on that until we decide whether this transition will be done within the existing arch/triplet or with a new one. I agree we should decide that pronto. And I think that 'we' is bigger than just Debian. If new autoconf (and gnulib) just turns this on within the existing arch/triplet then we, the distro, can't use those new versions unless we back out those changes, or until we decide that we are going to attempt this ABI transition within the existing arch/triplet. I'm OK with this being done either way (complicated transition within arch/triplet, or whole-world rebuild with new arch/triplet) once the size of the problem (and thus the amount of work) is reasonably understood and there is some consensus amongst distros. TTBOMK we need some more research before we can make that choice (although I realise some others are further down this road than I am, and yes I did plan to get to this point about a year ago, so apologies for slowness). Hence my suggestion of a full discussion on the cross-distro list. It is overdue. However my limited understanding as of right now says that autoconf 2.72 tying 64bit time_t to use of AC_SYS_LARGEFILE means that 2.72 can't be used in debian yet. So I currently favour not tying them together in this release. People have been using AC_SYS_LARGEFILE without 64bit time_t for many years now so it's not yet clear to me why that cannot continue. And even if it is a good idea to complete both transitions in the same upheaval we can't just have everyone who enabled LFS sometime in the last 20 years suddenly being forced into the time_t change (can we?). Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/
Attachment:
signature.asc
Description: PGP signature
