Re: Changes to abi=+time64 behavior (was Re: 64-bit time_t transition in progress)
Le Fri, Feb 09, 2024 at 10:20:40AM +0000, Simon McVittie a écrit :
> On Fri, 09 Feb 2024 at 05:03:23 +0100, Guillem Jover wrote:
> > if the maintainer
> > has requested it explicitly via DEB_BUILD_OPTIONS=abi=+time64, then
> > it should enable it also on i386 (changed behavior).
> >
> > The reason is that this does not now break ABI for any package (in Debian
> > or out of Debian) that might have already opted-in to that feature, it
> > does not require adding all the necessary flags manually if one wants
> > to opt-in on i386, and makes it possible to selectively enable time64
> > on [non-library] packages where the binary backwards compatibility make
> > no sense
>
> I think this is a good improvement. Another advantage of this change is
> that libraries that use time_t internally, but have been confirmed not to
> break ABI when it's enabled and don't call time_t APIs in their non-glibc
> dependencies, can easily opt-in to enabling it on i386 too. Some do this
> upstream already (like dbus and libsdl3 in experimental) but many don't.
>
> To put this another way, the argument for not doing the transition to
> time64-everywhere on i386 was "we don't want to break third-party i386
> binaries", but ideally we should still be enabling time64, even on i386,
> in the cases where it *won't* break third-party binaries.
So when introducing a new soname (no just a new package name), then one
should move to time64 even on i386 ?
But fundamentally, how do we know how third-party binaries are compiled ?
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: