Hi Bastian (2025.02.04_14:05:07_+0000)
> > > Provides: linux-libc-dev-amd64, linux-libc-dev-arm64, ...
> > We have two proposed provides schemes here, can we select one and add
> > it?
>
> Something like simple providers is the easiest to do.
So, by implementing this Provides scheme, Helmut's cross-bootstrapping
toolchain can determine which architectures are supported, and have a
target to Depend on.
The resolution of the issue brought to the tech-ctte requires figuring
out whether linux-libc-dev will take over providing these headers for
cross toolchain building, or whether cross-toolchain-base continues to
own the linux-libc-dev-${arch}-cross virtual package names (and provides
symlinks or duplicates of headers).
Thanks again for temporarily releasing the -cross virtual package names
while this is being discussed.
Before we can come to a conclusion on that, the elephant in the room
seems to be the question of the motivation for the migration to an
architecture all linux-libc-dev package. Let me try to distil this
question:
What is being gained by the transition to an architecture independent
package?
I see several pros and cons:
1. Advantage: Reduced overall disk usage on mirrors. 1x 2MiB
package replaces per-architecture 2MiB packages. For context, the
linux source produces ~1GiB of binaries per arch.
2. Advantage: This allows taking over linux-libc-dev-{arch}-cross, as
virtual packages, reducing the need for cross-toolchain-base to
duplicate linux source. And avoiding the need for cross-building to
create this architecture: all binary packages in bootstrap.
3. Disadvantage: Users get ~40 extra files (totalling 100kiB) per
architecture in Debian installed when they install linux-libc-dev.
(bug #1081826)
4. Disadvantage: linux-libc-dev is installable on architectures that it
doesn't actually support. No other package involved in
cross-bootstrapping exhibits this. This only applies to architectures
that aren't supported in the linux source package (helmut's A)
5. Disadvantage: cross-build tooling needs special heuristics to
determine which architectures linux-libc-dev actually supports.
(helmut's B) The Provides scheme above supports that.
6. Disadvantage: cross-build tooling doesn't currently support building
architecture independent packages. And that's quite understandable,
they should never need to be built unless we hit a situation like
this.
Is there anything that we're missing here?
Item 6 leads to more complex questions like how do we handle versions of
such packages? That's the fundamental issue here and it's where it gets
gnarly. It begs the question of whether it reasonable to patch sources
and build a binary package without a bumped source version.
When I get to this point, my feeling is: Yes, cross-building is breaking
assumptions that the rest of the archive is making. But it's (until now)
been working fairly successfully while keeping the approach as simple as
possible. That sounds like on balance a good thing.
Should some of those assumptions be codified into policy, if we want
them? Probably.
The change of linux-libc-dev to architecture: all has the effect of
causing a lot of non-trivial work for people doing cross-bootstrapping.
The balance of advantages vs disadvantages does depend a bit on how
valuable you see item 2 being. I imagine Matthias doesn't see any value
there.
With the pros and cons that I've seen, the weight of balance seems to go
against the arch all package. This is why people keep asking what the
motivation for the change was. If you have other motivations, please
share them.
Obviously, undoing the change would be a lot of work for you and the
kernel team, and we wouldn't want to put that on you. I'm not pushing
you to reverse the decision.
It would help if everyone saw the impact that they were having on each
other, and was able to weigh the costs of each option. Once we have some
common ground, we can come to conclusions on the questions raised.
Thanks for taking the time to understand people's questions and answer
them.
Stefano
--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272
