Hey Simon, Simon McVittie wrote: >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.
I don't have the list, I'm afraid. Arnd? >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). Hmmm. I didn't think Microsoft used *time_t* as such, but had their own 64-bit format based on an epoch in ~1600? >- 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) ACK. I'm in agreement here. I also personally don't see the same benefit to doing a 64-bit time_t transition for i386, using any of the models we've suggested. It's a legacy ABI that we should explicitly warn people will break. Have the Steam folks considered this issue at all yet, OOC? armhf is a different kettle of fish, without the same set of legacy binaries. There are *many* legacy proprietary binaries for the architecture, but the only ones that really matter are on other platforms (Android or iOS) and really not our problem here. :-) -- Steve McIntyre, Cambridge, UK. st...@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.
