Bug#1084908: arch:all linux-libc-dev causes problems to architecture bootstrap
Hi
On Thu, Oct 10, 2024 at 06:03:24PM +0200, Helmut Grohne wrote:
> 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.
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.
Sparc is dead, so any Debian using Linux that does not support it any
longer will not provide the basic support to use it. Sure, you could
hold on to an ancient linux-libc-dev, but this is then not longer
Debian. Heck, we even consider running a mix of stable and unstable as
unsupported. Why would we consider running a mix of
Debian-supporting-sparc and Debian-not-supporting-sparc a supportable
configuration? Technically all of this can work, but still not
considered supported.
All the examples of yours will immediatelly fail to build anything with
it. So what harm is done?
> 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.
I have no idea what you are talking about. I added the provides to
replace the existing cross packages with the functional identical
linux-libc-dev. You where not involved in this at all.
> 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.
I have to disagree. With this setup, we can support architectures that
are neither known by dpkg nor dak. This was not possible before and
required patching, aka making a derivative of the package. You can
still patch and rebuild it how you want and inject that modified package
into your workflow.
But now you can have a port without hand patched linux that is built in
a non-standard way and relying on internal and unstable package API,
just be talking and getting it added to the package first.
> 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.
This sounds like a bug in dpkg-cross, as it uses a not agreed on
interface to do it's work.
> 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.
If we talk about size, please go to gcc, which ships unstripped
binaries parts of the time. We don't need to talk about a highly
compressible 10 MB installed (up from 7 or so before) package.
Bastian
--
Immortality consists largely of boredom.
-- Zefrem Cochrane, "Metamorphosis", stardate 3219.8
Reply to: