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