Bug#1059929: release.debian.org: gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency
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
Reply to: