Re: Y2038 - best way forward in Debian?
[ Skimming through this - Arnd already responded ... ]
Guillem Jover wrote:
>On Tue, 2020-02-04 at 13:14:10 +0000, Steve McIntyre wrote:
...
>> 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. :/
Nod. :-(
>> * 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.)
ACK, that's feasible of course. It's not a *simple* upgrade, though.
>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.
Hmmm. Moving ld.so is *hard* - we were already bitten by stuff here
when we bootstrapped armhf initially. What we didn't know then (but
know now!) is that the final element of the path (i.e. the filename)
must be globally unique for glibc's code to work. We can't (for
example) just move ld-linux-armhf.so.3 to a new directory, we'd have
to rename the file itself. (Apologies if this is stuff you already
know - I think it's worth explaining for others too!)
>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. :)
I don't think this helps very much though - it's the embedded copies
of "time_t" all the way up the library stack that will break...
--
Steve McIntyre, Cambridge, UK. steve@einval.com
Armed with "Valor": "Centurion" represents quality of Discipline,
Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
concord the digital world while feeling safe and proud.
Reply to: