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. st...@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"
