Hi Simon,
On Sun, Jan 14, 2024 at 02:30:54PM +0000, Simon McVittie wrote:
> I'm testing an implementation of that. arch-test needs specific
> porting for each new architecture because of how it's written,
> so I'm not intending to use that directly, but it's easy to add a
> precompiled arch-test-like binary of the host architecture to the
> gobject-introspection binary package, and have the wrapper script try
> to invoke it and see what happens.
Thank you!
> Right - if we decide that qemu is not so good for some pair of (real,
> emulated) architectures, and actually we'd prefer to use some other
> user-space emulator like FEX or box86 for a particular pair, I don't
> want to have to make new sourceful changes in all 238 source packages[1]
> that produce public GIR/typelibs, plus however many packages produce
> private GIR/typelibs. It seems like it would be better to only change
> src:gobject-introspection and O(1) other packages.
You definitely managed to convince me that having the dependency on
gobject-introspection itself is preferrable.
> If the cross-toolchain team implements such a thing, it would be fine to
> add it as an alternative dependency in a later version. I'd prefer not to
> do that while it's still hypothetical, because until there's a concrete
> implementation we'd have no way to test it.
The draft on how this might work sounds quite nice. Of course, the devil
is in the detail, but my takeaway here is that there is a relatively
easy way forward for extending this mechanism to avoid a lock-in on
qemu and that extension does not require uploading tons of packages. My
fear was that your qemu dependency would make us inflexible for
extending it in future, but you successfully argued that it is actually
the other way round. For the reasons you give, I agree that going with
the direct qemu dependency is a good way to do it now.
> Another option (which could perhaps be combined with this) would be for
> the cross-toolchain team to define an interface to "the preferred way to
> run executables from architecture A if they can't be run directly", and
> then gobject-introspection could try that in preference to qemu. Meson
> calls this an "EXE wrapper", which seems like as good a name as any other.
Please allow me to defer this. I think we'll end up with a better
interface if we can gain experience with the moving parts in practice.
Your way of extending gobject-introspection will yield this experience
and hopefully we'll encounter another user of this scheme (again hard
coding qemu initially). And then, I hope to remember reading this
excellent mail of yours with that gained experience.
> - For the trivial case, cross-exe-wrapper-TUPLE:ARCH, where TUPLE and
> ARCH match, contains a /usr/bin/TUPLE-exe-wrapper which just runs its
> arguments as-is
> (like a trivial shell script that just does an 'exec "$@"')
I am thinking that perhaps this exe-wrapper could try forwarding to a
location in /etc (that normally does not exist) first and then fall back
to the behavior you describe. That way an administrator may supply an
external exe-wrapper and thus configure the wrapping for the entire
chroot solving the choice part that I took issue with.
> For the gobject-introspection use-case it would be possible to skip the
> cross-exe-wrapper package name and make g-i depend directly on
> cross-exe-wrapper-${local:DEB-HOST-GNU-TYPE}, but I think we would need
> the intermediate package name anyway if you want to be able to add
> Build-Depends: cross-exe-wrapper <cross>, for use-cases where the upstream
> build system will invoke TUPLE-exe-wrapper itself.
Yes. Please move forward with what you have without waiting for your
sketched cross-exe-wrapper machinery to appear.
> A Lintian check could make sense, perhaps? It could have a table of
> package names that should not be directly (build-)depended on, each with
> its allowed exceptions if any, for example:
>
> gobject-introspection-%-endian src:gobject-introspection
> gobject-introspection-bin src:gobject-introspection
> libmutter% src:budgie-desktop src:gnome-remote-desktop src:gnome-shell
> src:mutter
> liburweb0 src:urweb
> lighttpd-modules-% src:lighttpd
> perl-modules-% src:perl
> python-dev-is-% src:what-is-python
> python-is-% src:what-is-python
> python3-minimal python3
> python3.%-minimal python3.%
libbinutils src:binutils
The examples you give sound sensible, but I think lintian is not a
useful place to store it. The people best knowing these properties are
the respective package maintainers and not the (dormant) lintian
maintainers. Unfortunately, lintian does not have an archive-wide view,
so storing this outside lintian makes it difficult to check. The more I
look at problems like these, the more I think we should have some other
tool next to lintian that has an archive-wide view and can check such
properties. I'm also guilty of having written two specialized tools in
this area: the multiarch hinter and dumat are both specialized checkers
with an archive-wide view. I will not object to doing it in lintian
though as lintian is better than nowhere. I just cannot afford shaving
another yak. ;)
Helmut
