Hi On Sun, May 12, 2024 at 11:54:42PM +0200, Helmut Grohne wrote: > 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.
This is now https://salsa.debian.org/kernel-team/linux/-/merge_requests/1076 Not really tested however. Until cross-toolchain-base is rebuilt, we don't have any test subject. > > > 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. gcc-13, the native compiler, builds fine with headers in /usr/include and /usr/include/$multiarch. gcc-13-cross, the cross compiler, is reported to not build with this, however I can't verify that right now. > > 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. > > Given this, I fear I concur with your "This would not actually work." linux-libc-dev is also build-essential. This kind of rules out any same-source all-any trickery. Those packages will not show up at the same time, so are prone to make the whole toolchain uninstallable. Bastian -- Vulcans believe peace should not depend on force. -- Amanda, "Journey to Babel", stardate 3842.3
