On 07/01/19 09:41, Arnd Bergmann wrote:
> On Sat, Jun 29, 2019 at 6:21 PM Rich Felker <dalias@libc.org> wrote:
>> On Sat, Jun 29, 2019 at 03:36:19AM -0500, A. Wilcox wrote:
>>> On Jun 28, 2019, at 10:06 AM, Rich Felker <dalias@libc.org> wrote:
>>>> However Y2038 is not all that far off, desktop/server distros really
>>>> have rather little interest left in 32-bit archs (especially not
>>>> coordinating a costly ABI swap just for them)
>>> Please, please do not write off 32-bit desktop usage.
>> I'm sorry my wording contributed to a narrative that 32-bit is dead;
>> that's not at all my intent, but I can see how it could be harmful to
>> efforts to maintain support.
>>
>> My intent here is the other direction -- due to dominance of 64-bit
>> archs on desktop and server these days, there's much less effort being
>> put into the future of 32-bit ones, and I don't want to make a
>> decision here that would incentivize distros that don't already care
>> strongly about keeping 32-bit arch support to just drop it, rather
>> than going through a painful ABI swap-out.
>>
>> Thanks for your work continuing to press applications not to break
>> these archs.
> 
> I think there are three valid ways for distros to handle the time64
> conversion for 32-bit targets:
> 
> a) Decide to never convert but keep the time32 until *all* users have
>    stopped using 32-bit user space altogether (i.e. well before 2038).
>    Advantage: no ABI break at all.
>    Disadvantage: guaranteed to break in 2038, but likely earlier
>    because of long timeouts like key expiration times.
> 
> b) System wide rebuild (bootstrap) against newer libc with time64.
>    Advantage: No surprising ABI break
>    Disadvantage: requires reinstall instead of all user space,
>    breaks all third-party and custom binaries
> 
> c) Keep backwards compatibility in libraries, but convert the
>    distro one package at a time.
>    Advantage: If done right, users can upgrade over rolling
>    releases without ABIs breaking
>    Disadvantage: very hard to get right, and much more work
>    than the other two.
> 
> 
> Where would Adélie, Alpine and others using musl fit?
> 
>         Arnd
> 


Adélie rebuilds all packages for every release, and encourages users to
use `apk upgrade -al` which will /replace/ all of world for every
upgrade, so we'd be very happy with b).  Make everything as correct as
possible, as quickly as possible, with just a simple upgrade for users
(as long as they have no self-compiled software installed).

There is already no real "third-party" binary for 32-bit musl computers,
so I'm not sure if that's relevant.  For glibc binaries, we have gcompat
which could easily "shadow" time_t functions with 32-bit versions for as
long as glibc binaries continue to have a need.


Best,
--arw

-- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org