Package: linux-libc-dev Version: 6.6.3-1~exp1 Hi,
Ben asked me to file a bug report with the linux package describing the issues I see with linux-libc-dev being Arch:all. A. Multi-Arch: foreign is a lie linux-libc-dev declares being Multi-Arch: foreign, but it does not live up to the involved promise and cannot. Earlier, a dependency on linux-libc-dev:hurd-i386 would be considered unsatisfiable. With the current setup, it is trivially satisfied even though that doesn't make sense in any way. In a similar way, linux-libc-dev:sparc is now considered satisfied. While that makes some sense, the actual package does not ship any sparc files as 32bit sparc is dead. As such, linux-libc-dev now makes dependencies look satisfied when they should not be. B. Inability to figure out what architectures linux-libc-dev supports When linux-libc-dev was arch:any, architecture bootstrap would have to cross build it. Now that it is arch:all, architecture bootstrap can use the existing package. Sometimes. For release architectures and a few more, it is good, but fore exotic and dead architectures (e.g. sparc), one has to rebuild it with a modified configuration. In order to support figuring out when a rebuild was required, Bastian added provides for linux-libc-dev-$arch-cross due to my request. Neither of us saw how that would break cross toolchains and these provides are now reverted as a result. In any case, we're now back to the state where one cannot figure out whether a rebuild is needed. Ben asked me whether linux-libc-dev could simply support all relevant architectures, but there often is a check&egg problem. The linux package can only support architectures that dpkg knows about, but we want to perform test bootstraps way before adding a triplet to dpkg and one of the first things a test bootstrap does is building linux-libc-dev. So I generally expect that linux-libc-dev can never provide support for all architectures of interest and it shouldn't have to. Only once the bootstrap is tested and the parameters are known do we want to file the patches for a new architecture. C. Inability to produce a linux-libc-dev-$arch-cross package Now that linux-libc-dev-$arch-cross is no longer provided, dependencies on it are no longer considered satisfied, but the toolchain packages express dependencies on such packages. The architecture bootstrap tooling does not use cross-toolchain-base and instead creates such packages using dpkg-cross, but dpkg-cross cannot operate on arch:all packages. Therefore, we can no longer turn linux-libc-dev:$arch into linux-libc-dev-$arch-cross as is required by the cross toolchain. I note that I do not have a good understanding why the change from arch:any to arch:all was done. It does seem to reduce the cumulative size consumed by binary .debs on mirrors and note that a similar effect can be achieved by having a linux-libc-dev-common for the architecture generic headers and a per-arch symlink farm in linux-libc-dev. Ben, can you give some feedback on whether this report is useful for you in moving things forward? I'm not sure how actionable this actually is and welcome ideas on how architecture bootstrap should be adapted to cope with the changed packages. Helmut