Hi Bastian, On Sat, Oct 19, 2024 at 03:35:21PM +0200, Bastian Blank wrote: > On Thu, Oct 10, 2024 at 06:03:24PM +0200, Helmut Grohne wrote: > > A. Multi-Arch: foreign is a lie ... > All the examples of yours will immediatelly fail to build anything with > it. So what harm is done?
This is practically untrue. Even with current unstable packages, the sparc (32) bootstrap still succeeds. But then the use of sparc here was an example rather than a concrete issue. linux-libc-dev claims to support an architecture that it technically does not. That problem works the same way for obsolete architectures (such as sparc) as it does for new ones. The harm is being done. Quite simply, linux-libc-dev should ensure that dependencies on it are not considered satisfied when the architecture of the dependency is not practically supported. > > B. Inability to figure out what architectures linux-libc-dev supports ... > 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. Ok, you may see it that way (except for the "functional identical" part that evidently doesn't hold). I don't think it matters much who caused the mess we find ourselves in now. Let's skip the history bit. > 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. Fair enough. Please add arc, cksy, mipsr6el, sh3, sparc, and musl-linux-any. Thanks in advance. > > C. Inability to produce a linux-libc-dev-$arch-cross package ... > This sounds like a bug in dpkg-cross, as it uses a not agreed on > interface to do it's work. I stand corrected. dpkg-cross actually can convert arch:all packages in a reasonable way. Please consider item C a non-issue. > 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. I read this as you saying that size was not a motivation to change linux-libc-dev from Arch:any to Arch:all. But then, I do not understand the benefits of the change and why it was done in the first place. Obviously, we are still dealing with the fallout of an Arch:all linux-libc-dev after more than half a year. This bug is evidence of that dealing and demonstrates the significance of the downsides. Please enlighten me about the benefits. Helmut
