Re: Bug#1059929: release.debian.org: gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency
Hi Simon,
Thanks for your work on gobject-introspection cross building!
On Wed, Jan 03, 2024 at 07:22:26PM +0000, Simon McVittie wrote:
> - gobject-introspection-little-endian:any, a virtual package provided
> by g-i-bin, which is Multi-Arch: allowed
> (experimentally, apt and dpkg both seem to be happy to assume that
> this makes the gobject-introspection-little-endian virtual package
> behave as though it was also Multi-Arch: allowed)
Let me guess that this is the culprit. I also Cc apt maintainers for
their input.
> Or do I need to make gobject-introspection-bin Multi-Arch: foreign,
> drop the :any from gobject-introspection-little-endian:any, and
> replace the gobject-introspection-bin | qemu-user | qemu-user-static
> dependency by python3 | qemu-user | qemu-user-static or similar?
I am not sure that you are the one who should express a qemu dependency.
When we reason about dependencies, we care about how they behave
assuming that you can run them. Whether you can run an executable from a
package or not is something that is not expressed in our package
relationships. It's also rather difficult. Consider a few corner cases:
* Some amd64 can run i386.
* Most arm64, but not all, can run armhf.
* You may operate in a chroot with some external qemu-binfmt and thus
execute any arch.
* You cannot run hurd-i386 on amd64 even in the presence of qemu-user.
I probably have caused this in our discussion back in Cambridge where I
suggested to you that having a dependency on qemu could be ok. Given the
above, qemu quite likely needs more thought.
> My goal here is that you can install gobject-introspection:amd64 on an
> amd64 machine, or on any other little-endian machine that will be able to
> cross-compile amd64 binaries and then run them by explicitly invoking them
> via qemu-user, as discussed with Helmut Grohne at the recent Cambridge
> miniDebconf. (It has to be little-endian because g-ir-inspect and similar
> tools don't currently support byte-swapping fields in binary typelibs.)
When we considered whether cross building should imply disabling tests,
we went for "no, but yes by default". When you cross build a package for
i386 on amd64, sbuild and pbuilder will automatically add nocheck to
DEB_BUILD_OPTIONS and DEB_BUILD_PROFILES. However, you can opt out of
this behaviour to really run tests despite performing a cross build. I
think we need a similar mechanism for qemu integration.
When we talked about this, I was having in mind (but probably didn't
express this explicitly) that such qemu dependencies would happen in
Build-Depends only. This is different from what you do here and has
multiple implications:
* Your satisfiability problem with britney2 probably goes away.
* Every package that uses gobject-introspection needs to be modified
for this.
* We can annotate such qemu dependencies with a build profile e.g.
<cross !nocrossemu>. By default, such dependencies would only become
active for cross builds, but the second profile enables you to skip
them when you know that no emulator is required.
Other than this, let me note that M-A:allowed always seemed a little
annoying to me, because it makes an implementation detail visible to
consumers. Whenever you think you need M-A:allowed, you may instead
introduce a layer of indirection. In principle, you could add a real
binary packages: gobject-introspection-any-endian with Arch:any
M-A:foreign Depends:gobject-introspection-bin and architecture-dependent
provides. Then you can just depend on
gobject-introspection-little-endian without thinking about whether you
have to add :any.
Let me also note that the way you have gobject-introspection (the binary
package) now fills a similar role to pkgconf/pkg-config and qt5-qmake as
well as binutils-for-host and hopefully soon also gcc-for-host. That
pattern seems to work out rather well.
This probably isn't the final solution, but I hope my feedback moves you
forward in some way.
Helmut
Reply to: