On Fri, Feb 02, 2024 at 07:34:46PM +0100, Bill Allombert wrote: > On Fri, Feb 02, 2024 at 08:21:57AM -0800, Steve Langasek wrote: > > Dear developers,
> > As mentioned previously on debian-devel[6], we know that there are a number > > of library packages being included in this transition which we have not > > proven have an ABI affected by 64-bit time_t. This is because the > > engineering cost of analyzing the long tail of packages whose headers > > out-of-the-box fail ABI analysis under abi-compliance-checker is much higher > > than the cost of just changing the package name and moving forward with > > rebuilds. > Why not use reproducible build on a 32bit platform and see whether the new > library is different from the old one ? Well, if this suggestion had come 6 months ago when this plan was laid out on debian-devel, I think it would have been worth exploring. Though I would have still expected a large number of false-positives, because there would be differences for any library using time_t-derived types internally, *or* any filesystem access affected by LFS. > Do the libxxxt64 in experimental supposed to use the new ABI ? Because it > does not seem to be always the case. Is there a lintian test for that ? No. Earlier this had been the plan, but after discussing with Guillem we realized that wasn't actually relevant so we revised the plan on the fly and skipped dpkg in experimental. > Relying on dpkg-buildflags alone cannot be sufficient. I don't see any practical reason why not. -- 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
