cross-toolchain-base-devs team mailing list archive

[Helmut Grohne <helmut@xxxxxxxxxx>]

Hi Bastian,

I've intentionally snipped much of your reply as I think we two agree on
many of the aspects.

On Sun, May 12, 2024 at 07:35:09PM +0200, Bastian Blank wrote:
> > 1. API expectation of *-$arch-cross packages
> 
> I asked exactly that in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065416#55

I guess the best description is to be found in man dpkg-cross
"Conversion process" and even that isn't entirely helpful.

> > 4. cross-toolchain-base being bd-uninstallable
> 
> Which directly correlates to undocumented Build-Conflicts in the
> package.  They neither show up in the changelog or the commit logs.
> 
> >    I don't exactly understand why it declares them, but I guess that
> >    having a different set of kernel headers available in
> >    /usr/$DEB_HOST_GNU_TYPE would cause them to be picked up by the build
> >    and potentially cause misbuilds. cross-toolchain-base builds these
> >    packages and it also uses them during build of glibc.
> 
> So this reason is now gone.  linux-source-* and linux-libc-dev are
> similar enough in almost all cases.

It's not gone as non-virtual linux-libc-dev-$arch-cross packages are
still built from c-t-b. If c-t-b were to stop building them, I'd concur.

> > 6. Cross bootstrap cannot tell whether linux-libc-dev supports an
> >    architecture
> 
> Even in the past it could not.  It could try to build the linux package
> to see if it gets a working linux-libc-dev.  Or have other code to hack
> around, like changing the config.

In the past, there was no need to tell. It would always build
linux-libc-dev. Now that linux-libc-dev works for many but not all
architectures, there is a need to tell.

> Actually linux-libc-dev-$arch-cross is uncommunicated and uncoordinated
> duplication of exactly the same content as linux-libc-dev.

It is news to me that it is uncommunicated and uncoordinated, but that
very accurately matches the rest of the disagreement. Yes, it is
duplication.

> 9. linux-libc-dev-*-cross provides incompatible headers to
>    build-essential
> 
>    Both linux-libc-dev and linux-libc-dev-*-cross provide the linux/*
>    includes that are used by the compiler but of different versions.  It
>    is undefined if those can work with the (always older) asm/* provided
>    by linux-libc-dev-*-cross.

Yes, this is a problem. It kinda is the same problem that we have with
libc6-dev vs libc6-dev-$arch-cross and is why libc6-dev declares
versioned breaks for libc6-dev-$arch-cross.

> > 3. cross-toolchain-base could build a linux-libc-dev-cross package
> >    that Provides the earlier -$arch-cross packages and contains a
> >    similar symlink farm to linux-libc-dev.
> 
> This requires coordination of the versions and strict enough
> dependencies.  So linux-libc-dev-cross would need to come out of the
> same source as linux-libc-dev.

Technically speaking, a linux-libc-dev-cross package could be built from
c-t-b. It would just inherit all the other problems including your
problem 9 from the previous approach and only address the space aspect.
I listed it more for completeness sake than suggesting we actually go
for this.

> > 4. cross-toolchain-base could drop its Build-Conflicts. This may cause
> >    further problems though.
> >    Patch: https://bugs.debian.org/1067370#17
> 
> The build will now see multiple architectures of headers.  So it needs
> to handle this both for native (where build-conflicts can't be used
> anyway) and cross the same.

I don't understand what you are trying to say here. c-t-b only builds
Arch:all packages, so the terms native and cross appear to not apply.
Then again we also don't know what "further problems" are. I hope
Matthias can shed some light here.

> On Sun, May 12, 2024 at 01:53:33PM +0200, Helmut Grohne wrote:
> > 2+3+6+7. linux-libc-dev could be split into linux-libc-dev-common
> >    arch:all m-a:foreign and the symlink farms could be kept in
> >    linux-libc-dev:any m-a:same retaining the size reduction.
> 
> This would not actually work.  linux-libc-dev-common would only contain
> known architectures.  So the current "change config, build
> linux-libc-dev" will not longer work as well.  This package would then
> depend on a linux-libc-dev-common without the headers for this
> architecture.

I agree that it is not as simple as I pictured it. I was imagining that
a m-a:same linux-libc-dev could simply contain all the
architecture-dependent stuff. For many architectures that would
practically work initially, but there is no bijective mapping between
kernel architecture names and Debian architecture names, so for
directories like /usr/lib/linux/uapi/arm is is unclear whether it should
be part of linux-libc-dev:armel or linux-libc-dev:armhf or
linux-libc-dev-common.  Even for /usr/lib/linux/uapi/arm64, it is not
clear whether that should be part of linux-libc-dev:arm64 or
linux-libc-dev:musl-linux-arm64 or linux-libc-dev-common. You are
implicitly resolving this to linux-libc-dev-common and conclude that
headers would then go missing.

We could now add another layer of indirection and add an arch:all binary
package for every kernel architecture name, but that would go against
the original goal of reducing size.

Given this, I fear I concur with your "This would not actually work."

Helmut