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. <ballo...@debian.org> Imagine a large red swirl here.
