Thank you for your rigorous scrutiny regarding the proposed plan. It was a blindspot on my part that dpkg-buildflags was not a policy mandate, because by this point I'm quite *used* to using dpkg-buildflags to manage transitions in the default build flags for the compiler.
What I hadn't taken into account is that in those previous transitions, the consequence of failing to use dpkg-buildflags in a small number of packages was that those packages did not get certain improvements (in QA, performance, security, etc) - whereas in this case the consequence of missing these flags is instead a potentially critical crasher bug due to ABI skew. I am delayed in responding to this feedback in part because the realization pulled me up short and caused me to have to take stock internally of the overall transition plan. I think we do need to change the default gcc behavior on our 32-bit archs to correctly manage this transition. I believe the correct sequence now should be: - change (the default) gcc to emit the necessary preprocessor flags by default. - also change dpkg-buildflags to emit them by default (abi=+time64: -D[...]; abi=-time64: -U[...]). - do the mass uploads to unstable. (I don't think the critical path here should block on changing the default behavior of non-default compilers - either non-default gcc versions or llvm. Packages that *both* use a non-default C compiler to build *and* don't honor dpkg-buildflags are a corner case, and we can identify any affected packages retrospectively rather than having them delay the main event to the detriment of other development in unstable.) On Wed, Feb 07, 2024 at 10:12:33AM +0000, Bill Allombert wrote: > Le Fri, Feb 02, 2024 at 08:23:42PM +0100, Bill Allombert a écrit : > > > I don't see any practical reason why not. > > Because packages are not required to use dpkg-buildflags. > And more generally, does this scheme will require to build third-party > packages on 32bit Debian system to set > CFLAGS=D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 > or will this be made the default in gcc or glibc ? On Thu, Feb 08, 2024 at 08:07:19PM +0100, Ansgar wrote: > On Fri, 2024-02-02 at 08:21 -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] > How does this work when a user builds their own software using any > library build with abi=time64? They will still get a 32bit time_t & > others unless they use dpkg-buildflags as well, won't they? > If we already change ABI, why not change this in the toolchain (glibc, > gcc) so also user-build packages use the correct ABI? That was what > happened for other ABI changes like the C++ ABI change as far as I > remember. Right: addressing this in the default behavior of the default compiler sorts out the non-package build question also. I (and colleagues on the Ubuntu Foundations team) will work with the gcc maintainer to establish a timeline for when we can have such a change landed. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
