Hi Bastian (2024.10.19_09:35:21_-0400) > What you describe here is a headers only library. It is consensus > within Debian that those exist and are shipped as arch:all. They don't > provide further architecture clues in the dependencies, but you need to > know or convey this information by failing to build.
I think in most (all?) cases, they don't have architecture-specific headers. So that applying that consensus here may be not be that useful to this case. In general arch:all packages are preferable to arch:any, for the sake of the size of the archive. But sometimes violating that is necessary. It sounds like changing linux-libc-dev to arch:any could be helpful to the cross-bootstrappers. That's something that happens outside the archive, but is also part of the lifeblood of the project. Architectures come and go, and we've been trying to make this process easier. It's one of our strengths as a distribution. > > 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. > > No, it can not. We can not have arch:any -> arch:all dependencies > within the same source package this deep in the toolchain, especially as > those require = dependencies. Would you expand on that a bit? I see a concern on a -common package: There are risks of arch:all and arch:any packages building at different times on the buildds, and possibly being published in separate mirror pushes. Leaving build-essential uninstallable if the builds don't all succeed before the arch-all package publishes. If so, avoiding a -common package and having linux-libc-dev be pure arch:any could be a reasonable solution? (At a cost of size) Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
