Changes to abi=+time64 behavior (was Re: 64-bit time_t transition in progress)
Hi!
On Fri, 2024-02-02 at 08:21:57 -0800, Steve Langasek wrote:
> Once all of these packages have built in experimental and we have identified
> and addressed all adverse interactions with the usrmerge transition, the
> plan is:
>
> - dpkg uploaded to unstable with abi=time64 enabled by default[5]
> [5] https://bugs.debian.org/1037136
I just realized recently that I think it'd be better to change a bit
the semantics of the abi time64 feature on i386, where by default it
will not include the time64 flags (as before), but 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 packages where the binary backwards compatibility make no sense
(such as dpkg itself, where this has already been requested and where
I mentioned in the libselinux report that I'd like to do that, and
where otherwise the port might be unable to install stuff at all).
Otherwise the majority of packages should have no need to explicitly
declare abi=+time64 as that's going to be the default (except for i386).
I've queued these updated semantics, including manual page updates and
unit tests into the next/time64 branch
<https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/log/?h=next/time64>
(the previous semantics and incomplete commits are still in the
next/time64-default branch), which I'd be merging into main close to
the release, once there's agreement on the dpkg upload date.
If someone has issue with this, let me know and we can discuss the
merits of going some other way.
Thanks,
Guillem
Reply to: