On Sat, 06 Jan 2024 at 10:16:28 +0100, Paul Gevers wrote: > I guess there are exceptions we could accept like from > src:steam-installer (which doesn't use :i386 or :amd64 at the moment if I'm > correct)
src:steam-installer avoids using :i386 in dependencies because I was under the impression that explicitly naming an architecture like that wasn't supported/allowed. Instead, steam-installer:amd64 Depends on steam-libs-i386, which only exists in the i386 Packages file (and is M-A: foreign so that it can satisfy the dependency from an amd64 package). I thought this was the standard workaround for something in the stack (apt? dpkg? the multiarch spec?) not allowing saying what I actually mean, which is: steam-installer:amd64 Depends on both steam-libs (implicitly :amd64) and steam-libs:i386. nss-mdns and the NVIDIA drivers both used this technique in the past, and Wine still does (it's called wine32 rather than wine-i386 but the principle is the same). If an explicit dependency on steam-libs:i386 would be valid, I'd be happy to use that, and remove the steam-libs-i386 binary package as redundant. Because it currently uses a lockstep dependency, I think we'd have to relax it to >=, and then keep it as a transitional package until after trixie. > packages being blocked for useful use cases (that we could hint > through, but that britney2 would consider non-installable, so not protected > from then on) I agree that explicit cross-architecture dependencies like the ones in steam-installer, nss-mdns and nvidia-graphics-drivers are quite rare, and it seems fine for them to need some manual intervention. The only use cases I know of are for proprietary i386 binaries that we can't just recompile as pure amd64 (like Steam and whatever Windows program you want to run via wine32), or for packages that support those (wine32 itself, graphics drivers, NSS plugins and so on). Maybe if cross-architecture dependencies were less of a special case, we might see a bit more use of this when cross-compiling (gcc-aarch64-linux-gnu Depends libc6-dev:arm64, making libc6-dev-arm64-cross unnecessary?) or for firmware for coprocessors (like if your x86 machine has a peripheral with a riscv64 processor that can run ordinary riscv64 code). > I think this bug report is one of only a couple over the years > that requested anything on this front This bug #1059929 involving gobject-introspection_1.78.1-9 is different from things like steam-installer and nss-mdns: in the steam-installer case I had to ask the release team (a while ago) to apply some force to work around a known limitation in britney2, but in the gobject-introspection case, my hope is that it can be resolved (possibly by a bug fix in britney2, or possibly by changing gobject-introspection) without forcing the installability check to be ignored. Yes, the dependencies are meant to be cross-satisfiable (and the package would be a lot simpler if that wasn't the goal), but they are also meant to be more trivially satisfiable in a single-architecture scenario. It shouldn't matter for this particular use-case whether you can *actually* cross-compile using gobject-introspection, because the scenario that I'm asking britney2 to evaluate when it considers migrating gobject-introspection is whether it's installable within a limited packaging universe that contains only :amd64 and :all packages - which is something that apt and dpkg are happy with. smcv