Hi
On Tue, Feb 04, 2025 at 05:25:08PM +0000, stefa...@debian.org wrote:
> So, by implementing this Provides scheme, Helmut's cross-bootstrapping
> toolchain can determine which architectures are supported, and have a
> target to Depend on.
I just read through rebootstrap, which I think is what Helmut is always
talking about. It uses dpkg-cross, so is already using undefined
behavior of linux-libc-dev to do it's work.
My current version of it does this now:
| Provides: linux-libc-dev+support-debian+alpha (= ${binary:Version})
> 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?
> 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)
Yes. It only supports architectures that are defined as Debian.
> 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.
You mean "bootstrap tooling". And yes, that part I missed in my initial
assessment,
> 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.
The problem was: dpkg-cross was not able to do it's work with an
arch:all linux-libc-dev. But it might have failed with any change of
linux-libc-dev, because it relies of undefined behaviour. So not a
disadvantage, but inherent instability of the dpkg-cross approach.
Or actually an advantage, because we can remove this instability and
reduce the complexity.
> Is there anything that we're missing here?
- It can provide headers for multiple architectures at the same time.
- It could even handle debian architectures mapping to multiple
multiarch identifier and kernel arches (like hppa did kind of).
- debian-ports can import it without going through the manually handled
"unreleased" part of their archive, even before ftp-master knows about
an architecture.
- Reduces the part of the package API that is used in an undocumented
way via dpkg-cross.
> Should some of those assumptions be codified into policy, if we want
> them? Probably.
I don't know. Right now the whole cross-building stuff violates the
policy, how would we clean this up?
I'm not even sure about arch:all. We currently have no problems with
such packages only working on some architectures, if by dependency or
actually failing to work.
> 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.
The impact was rather small. Only two other parts where actually
affected, and none of them was our endusers.
The bootstrap stuff was affected, which I missed at first. But is all
contained within two scripts that control everything. And the rest of
that script is patching other packages quite havily already.
The other is cross-toolchain-base. But here the impact is still
completelly unknown or at least does not show up within Debian.
Bastian
--
It is a human characteristic to love little animals, especially if
they're attractive in some way.
-- McCoy, "The Trouble with Tribbles", stardate 4525.6
