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/