Re: Revisiting 64-bit time_t

[Rich Felker <dalias@libc.org>]

On Mon, Jul 01, 2019 at 09:50:31AM -0500, A. Wilcox wrote:
> 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?
> 
> 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.

I think this ignores the reality that a lot of users of any distro
except Debian pretty much *have to* build some software from source,
since there's so much more software out there than what you can
package without contributor bases and infrastructure that size. If you
break or switch ABI, you invalidate all the existing self-built
software a user has (unless they static-linked, but that might not be
an option if the software needs dlopen).

Admittedly distros are not doing a great job with this already. For
example when I updated Alpine, a bunch of my self-built software
stopped working because it uninstalled the old boost packages with the
matching API/ABI. I'm not sure how well Adélie fairs in this regard.
But in principle it's something that should be able to work. And this
is a large part of the motivation for why musl committed to stable
ABIs and of the motivation for musl rather than improving uclibc.

Rich