On Sat, 2024-10-19 at 15:35 +0200, Bastian Blank wrote: > Hi > > On Thu, Oct 10, 2024 at 06:03:24PM +0200, Helmut Grohne wrote: [...] > > > 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. [...]
Currently gencontrol.py runs dpkg-architecture to find the multiarch
triplet for each Debian architecture. So it's not possible to add any
architecture that's unknown to dpkg in unstable.
Are you proposing to extend our config schema so we can define those
triplets within src:linux?
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?
Ben.
--
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy others.
signature.asc
Description: This is a digitally signed message part
