Hi! On Tue, 2022-09-20 at 12:03:41 +0200, Helge Deller wrote: > Package: dpkg > Severity: wishlist > Tags: lfs, hppa
> I've seen quite some lfs errors (on 32-bit platform) with packages in > the last weeks. > Isn't it time now (year 2022), to take lfs down from "future" feature > to "standard" feature and enable it by default? Ideally? Yeah, I'd love that. In practice this unfortunately cannot be done. I think not even with something like <https://wiki.debian.org/Teams/Dpkg/Spec/DpkgDevCompatLevel>! :/ > I mean, instead of requiring package maintainers to add: > DEB_BUILD_OPTIONS="future=+lfs" > or > DEB_BUILD_MAINT_OPTIONS="future=+lfs" > > simply enable this feature now by default? > > With that everyone (on a 32-bit platform) would e.g. get: > > dpkg-buildflags --get CPPFLAGS > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 > > I have to admit, that I don't know if some packages would fail to build > with it, but if they do, they should be fixed.... Besides potential build failures (although those should have been sorted out when building on 64-bit arches), the main problem here is that this would break ABIs everywhere, which for shared libraries, plugins, modules and similar would be catastrophic. And as I mentioned above I don't think it would be safe to enable automatically even with some kind of dpkg compat level, as this might still break the ABI, and not be noticed until run-time when things start to misbehave/segfault etc. So, as mentioned while I'd really like for us to be able to complete the LFS switch, which has been going on for years now, I'm afraid it cannot (at least currently) be done automatically from the dpkg side. And thus I'm inclined to mark this as wontfix and close in a bit. :/ Thanks, Guillem
