Hi,
On Tue, Feb 04, 2025 at 05:25:08PM +0000, stefa...@debian.org wrote:
> 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?
In addition to all listed points, it also temporarily breaks
creating chroots for archs when the src:linux build for a given arch
and for arch:all end up in different dinstall windows. In this time
linux-libc-dev will not be visible to debootstrap. This behaviour
was observed f.e. on 2025-02-03.
Chris
