Hi Guillem,
On 9/20/22 12:19, Guillem Jover wrote:
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. :/
Guillem, thanks for the extensive answer!
I had suspected such an answer, but it's probably right.
You can close this ticket.
Thanks,
Helge
