Hi!
On Tue, 2020-02-04 at 13:14:10 +0000, Steve McIntyre wrote:
> 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.
I think there is still work pending in glibc to expose both 32-bit and
64-bit interfaces at the same time? (Currently it seems to be either-or.)
I'd like to use this for example in libbsd, to make a smooth
transition similar to the one made in glibc, w/o needing to bump the
SONAME.
> 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.
Well, I guess such a new (conditinally selectable) name could be
coordinated with glibc upstream? Say bump 32-bit ports to use libc6.1?
(We already have precedent in some ports that do not use the same
prevalent SONAME, such as libc6.1, libc0.1 and libc0.1.) But it would
indeed involve lots of work, with massive amounts of package renames. :/
> 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).
> *** 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:
(If we are going for this, I'd say it might make sense to consider
also enabling LFS, although that might be a dangerous change, see
the lintian tag for the rationale. :)
> * users would *not* be able to simply upgrade from one to the
> other, due to lack of binary compatibility
I think this conclusion stems from an incorrect premise. See below.
> 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.
A new dpkg architecture must use a different triplet, as these are
required to be bijective. See “lpia” for a previous example of this.
(This would then make it possible to cross-grade.)
In addition if we are using a new multiarch triplet, and need to
rebuild the world, are going to be ABI incompatible anyway, we might
as well use a proper multiarch-qualified ld.so pathname that does
not collide with anything.
I also think we have a C option, which would be something like:
C Do a transition equivalent to the LFS one, by either switching
libraries opportunistically to 64-bit time_t on their next SONAME
bumps, or by updating them to provide 64-bit variants of their
interfaces along their 32-bit ones, as done in glibc. Of course
the main problem here is that the LFS "transition" is not one we
should be very proud of, as it's been dragging on for a very long
time, and it's not even close to be finished…
<https://lintian.debian.org/tags/binary-file-built-without-LFS-support.html>
(Hmm there seems to be something borked with lintian.d.o, as the
general tag numbers seem extremely low. :)
Thanks,
Guillem
