Hi Bastian, On Wed, Dec 04, 2024 at 10:40:59PM +0100, Bastian Blank wrote: > On Thu, Oct 24, 2024 at 01:29:31AM +0200, Ben Hutchings wrote: > > Do we really want to be on the critical path for the early stages of > > defining a new architecture, including any renaming that might happen > > before it's added to dpkg upstream? > > Which early stages? We have three stages: > - Before the arch reaches anything related to Debian. In this stage, it > does not matter if the package it all or any, it can be patched.
This is the stage I am concerned about. You claim that it would not matter whether the package is all or any, but my experience is otherwise. With the exception of linux, the cross bootstrap tooling does not build any Arch:all packages at all. Adding that support has not been trivial and the way it is implemented still is violating internal principles making its code fragile. In particular, for each combination of package name and architecture, there would only be one binary package - with the exception of linux where the would now be two (the unpatched one from the archive and the patched one). I'd have to somehow remove linux-libc-dev from an unstable amd64 mirror. The all versus any also poses the problem that it becomes unclear whether it has to be rebuilt. When it was :any, it always had to be built, but given that its M-A:foreign is a lie and that we had to remove the Provides, it is difficult to tell whether a rebuild is needed. In now find it all surprising that we (at least Ben, Bastian and me) agree on patching linux at this stage being the right approach. My earlier impression was that Bastian preferred src:linux to participate in this early stage of the bootstrap and I have expended mails to argue otherwise, but that seems unnecessary now. Instead, the question becomes how we can make that patching easy and the disagreement becomes whether Arch:all makes that sufficiently easy. Even though I cite building Arch:all as difficult in the bootstrap context, the more pressing issue from my side is the inability to tell whether a rebuild is needed by looking at package relations. Dealing with unsatisfiable dependencies is something, I've developed ways to deal with. Dealing with wrongly satisfied dependencies is a totally different thing to me. As it stands, linux currently is the only package involved in architecture cross bootstrap that produces false positives in dependency satisfiability tests used for scheduling builds. > - While it lives on -ports, but dak does not know about it. In this > stage, the package needs to be managed manually. > - While it lived on -ports and dak knows about. In this stage, support > can be added as arch:any. As an architecture enters -ports for the first time, it must have its triplet included in dpkg. At that time, I think it is reasonable to ask src:linux to include its headers. linux also is uploaded so frequently that it will not be practically blocking any port progress. The step that usually takes much time and convincing is getting an architecture into dpkg. I do not see an Arch:all linux-libc-dev as being a hindrance to these later stages. Helmut
