Hi Guillem,
On 1/24/23 11:55, Guillem Jover wrote:
On Mon, 2023-01-09 at 15:20:41 +0100, Helge Deller wrote:
Package: dpkg
Severity: important
Tags: lfs, hppa
Version: 1.21.17
Tags: hppa, patch, ftbfs
This is a follow-up for #1020335 regarding "enabling LFS by default
on hppa arch".
It's unfeasable to try to fix every package which fails on
hppa due to missing large file support. The problem is, that failures
happen undeterministic and silently at runtime which makes it often
really hard to find the real cause and in summary wastes a lot of
developer time.
Sorry I didn't answer before, I got entangled doing the final changes
for the toolchain freeze.
That's ok.
First of all, I do understand your position here, and the desire to
leave behind any problems related with LFS. As I think I've mentioned
before, I'd love if we could do that globally, but unfortunately I
don't think that's feasible :/ (but perhaps I'm wrong about it!).
Said that, I'm still rather uncomfortable with this request, even if
it's now at least limited to an hppa-only change.
Yes, it would only affect hppa.
The potential reach of the ABI breakage seems to me like an unknown
that has not been evaluated in depth.
That's true, and it's probably not really fully evaluatable.
On the other side, it's also not evaluateable how much is currently
broken already because of the missing LFS support. Every program which currently
is in the archive and which wasn't compiled for LFS can break at any time
for any user when it's running on bigger discs.
And I understand that you
mentioned that as port maintainers you don't see such ABI breakage as
a big issue, but still.
The attached patch is trivial and enables LFS by default for the hppa
arch only. Guillem, would you mind applying the attached patch?
I've been pondering over this, and my concerns are:
* unknown amount of potential ABI breakage (this would also be
interesting to know to evaluate similar potential switches on
other 32-bit arches).
That's why I think hppa is a great platform to test and to get such
knowledge. It's a niche platform, very little users, just living in
debian-ports (as it's not a fully-supported debian architecture), as
such just living in "sid" (as we don't provide stable debian releases).
If you would try that on x32 or arm it will be much more complicated.
So, the overall impact is small.
* how to communicate this potential breakage to hppa users.
I can send to the mailing list.
* whether that breakage might cause users to report bugs against
packagers, whose maintainers cannot do much about, or that might
end up on dpkg for incurring that breakage.
The workaround is easy, just add "future=-lfs" and the program will
be compiled in it's current form.
On the other side, without this change, currently existing users may report
LFS issues regarding current packages because it fails to run, and in
the current form the package maintainer can't do anything about it either
(maybe due to packages which they depend on and which have LFS disabled too).
* whether the change might break hppa builds (unknown amount too?)
that might need changes to source packages.
It will, but I think just a small amount.
There will be some core packages which need to add "future=-lfs", e.g.
glibc, since they handle build for both by themselves already.
* need to inform all maintainers about the potential breakage.
* all the above compounded with the current ongoing freeze.
Agreed. No such change during the freeze.
But after the freeze it would be good to change it.
* this ABI breaking change, potentially being used as precedent for
other similar ABI change proposals, breaking ABI port stability
guarantees.
Given the above, I think I'd like have more information on the table,
and I'm not sure how urgent you see this change, but I think right now
during the freeze is probably not the right time to entertain?
It's urgent, because I see packages failing to build from source on
the buildds. Often it's just that they run testcases after building
and then fail to find their sources, test scenarios, ....
So, after the freeze....
I think some of the information I might like to see, might perhaps be
a tall ask, but I think it would be very useful for hppa and for other
ports as well. And in the end I think given that this would also
probably end up having a global impact on maintainers, it might be
worth bringing it up on debian-devel, once there's a more clear
picture?
Does the above seem reasonable?
Sure. The change has to happen anyway (btw, for 64-bit time_t too, but
it's probably more invasive), and I think it would be good to have
multiple arches change it at the same time...
Helge
