Y2038 - best way forward in Debian?

[Steve McIntyre <steve@einval.com>]

Hey folks,

Apologies - I should have sent this mail quite a while back. :-/

Arnd Bergmann (in CC) has been helping to drive a lot of work to solve
the 2038 problem in the Linux world. I've spoken about this before,
e.g. at DebConf17. He's been pushing a lot of updates throughout the
Linux kernel, and has also been analysing code elsewhere. He's very
interested in how to update complete systems like Debian too, and we
spoke about this some time ago.

The kernel is *basically* fixed now. Internally, data structures
should now be safe. There are a small number places where 32-bit time
is still a thing, but it's in hand. A number of syscalls, ioctls,
etc. have needed updates for the user-kernel interface level. glibc is
the place that needs to care about most of this.

The glibc folks have taken an interesting approach.

 * 64-bit ABIs/architectures are already using 64-bit time_t
   throughout. The design is sane and so we should already be mostly
   safe here, modulo silly code bugs (we'll always have those!)

 * 32-bit ABIs/arches are more awkward. glibc will continue *by
   default* to use 32-bit time_t to keep compatibility with existing
   code. This will *not* be safe as we approach 2038.

 * 32-bit ABIs/arches *can* be told to use 64-bit time_t from glibc
   upwards, but this will of course affect the ABI. Embedded uses of
   time_t in libraries will change size, etc. This *will* be safe for
   2038.

So, we're all fine? Not so much: for our 32-bit Debian arches, we will
need to basically rebuild the world to be 2038-safe. When we had to do
something like this in the past, to deal with the libc5->libc6
transition, we had an SONAME change in libc to work with. We decided
to append the "g" tag to the names of our library binary packages to
signal that a library was built against libc6. We can still see some
of the effects of this in the archive, many years later
(e.g. zlib1g). The problem now is that we will *not* have an soname
change here to help identify code compatibility on the 32-bit front.

Arnd scanned the library packages in the Debian archive and identified
that about one third of our library packages would need rebuilding
(and tracking) to make a (recursive) transition. We can see two
different possible routes to follow:

 A Follow a similar path to last time (rename library packages). This
   will allow us to do partial upgrades, but the cost is that a vast
   number of packages will need work to make this happen,
   *potentially* building library packages twice to allow us to
   continue both 32-bit and 64-bit time_t support forwards for a
   while. This effort will be *needed* only for the sake of our 32-bit
   ports, but would affect *everybody*.

 *** OR ***

 B Decide which 32-bit ports we expect to care about by 2038, and
   re-bootstrap new versions of those ports *with different
   names*. This would allow most of our developers to ignore the
   problem here (as 64-bit arches are not affected) and let a smaller
   number of people re-bootstrap with new ABIs with 64-bit time_t
   embedded. There are some downsides here:

   * we would end up with two versions of some ports for a short time
     - probably one release of overlap

   * users would *not* be able to simply upgrade from one to the
     other, due to lack of binary compatibility

   We *would* be able to run old and new ABIs on top of the same (new
   enough) kernel (e.g. for buildds), so a lump of this would just be
   simply building the new world and filing bugs where needed.

   We'd need to decide exactly which of our 32-bit ports we would want
   to do this path with (probably armhf->arhmft?, maybe
   armel->armelt?, i386->i386t?. mipsel???). Due to the libc6 soname
   continuity, we will most likely *not* end up with a different
   visible ABI via the triplet and the runtime linker, so old/new
   multi-arch will be impossible.

So, which way should we go? My own personal gut feel matches Arnd's,
which would be route B. Some of us already have fair experience with
bootstrapping new arches, and we could almost just crank the handle
for most of this work.

What do people think here? Which do you think is the better path? Feel
free to point out things you think I may have missed. We should get
started on this soon - the longer we leave it, the more likely it is
that we'll see 2038 bugs biting people.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"Yes, of course duct tape works in a near-vacuum. Duct tape works
 anywhere. Duct tape is magic and should be worshipped."
   -― Andy Weir, "The Martian"