Re: Y2038 - best way forward in Debian?
On Tue, 04 Feb 2020 at 13:14:10 +0000, Steve McIntyre wrote:
> 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.
Is a list of affected/unaffected packages available? (I know they'll
be long lists.) Depending on how high up the stack they are, the right
approach might change.
Thinking about i386 specifically, since the tradeoffs for that architecture
are likely to be a little different due to the prevalence of proprietary
binaries, the use-cases I am aware of are:
- Old hardware that doesn't implement amd64.
Breaking ABI would help here, but equally, this use-case seems likely
to go away "naturally" in the next 10? years (and for example Ubuntu is
already relegating i386 to a second-class-citizen status as a multiarch
library stack on amd64 systems, with no kernel or full bootable OS).
- amd64-capable machines that have inherited a legacy i386 installation
because their owner doesn't want to reinstall or sidegrade to amd64.
Breaking the i386 ABI seems like it would be counterproductive here:
they'll still need to reinstall or sidegrade, and sidegrading from
i386 to i386t would probably be very crash-prone, since those will
presumably both have to be represented by ELF32 x86 binaries?
- 32-bit Wine (to run 32-bit Windows programs).
On the Unix side, breaking ABI would maybe help. On the Windows side,
Wine needs to match whatever Microsoft does to solve this problem
(apparently time_t already defaults to 64-bit on Windows, but older
binaries will presumably use 32-bit time_t forever).
- Running old proprietary or otherwise sourceless binaries (e.g. games).
Breaking ABI is counterproductive: we can't recompile the games anyway.
Some solutions for running these (e.g. the Steam Runtime used by Steam)
rely on host libraries being approximately ABI-compatible with the ones
the binaries were compiled against, because they need to fetch graphics
drivers and their dependencies from the host system, otherwise they
could not work on recent GPUs (although by 2038, with faster CPUs, we'll
hopefully be able to run 2010s games at acceptable performance with
software rendering like llvmpipe, which would sidestep this issue).
(See the slides/video from my recent FOSDEM talk for more details)
smcv
Reply to: