Hi Bastian, On Thu, Dec 05, 2024 at 03:30:53PM +0100, Bastian Blank wrote: > What kind of information can this dependency satisfiability test use? > > Something like this? > > | Provides: > | linux-libc-dev-supports (= amd64-0), > | linux-libc-dev-supports (= arm64-0), > | linux-libc-dev-supports-multiarch (= aarch64-linux-gnu-0), > | linux-libc-dev-supports-multiarch (= x86-64-linux-gnu-0),
Using Provides is the natural approach indeed. Encoding the architecture into the version may technically work, but it feels really strange. Earlier, I proposed encoding it into the provided package name like linux-libc-dev-arm64-cross, but we all know how that went and I would not have proposed it if I had seen how it broke other pieces. Still if we were to just drop the "-cross" suffix and go for a very similar version. Provides: linux-libc-dev-amd64, linux-libc-dev-arm64, ... In any of these cases, I can inject extra dependencies and have dose-builddebcheck correctly determine whether the existing linux-libc-dev satisfies what is needed. As stated elsewhere, I still don't understand what we gained by switching from Arch:any to Arch:all, but maybe I don't have to. A solution that adds any of these Provides is what I'd call good enough in practical terms for the purpose of bootstrapping. Helmut