Re: mapping from debian arch to qemu arch

[Christian Kastner <ckk@debian.org>]

Hi all,

apologies for the late reply.

On 2022-12-28 17:20, Johannes Schauer Marin Rodrigues wrote:
> Quoting Michael Tokarev (2022-12-25 08:01:31)
>> BTW, does sbuild really needs qemu-system (and sbuild-qemu to begin with)?
> 
> sbuild-qemu uses the autopkgtest backend of sbuild to run builds with qemu
> isolation. So for building packages, sbuild-qemu only uses qemu-system-XXX
> indirectly via autopkgtest. The sbuild scripts that need qemu-system-XXX
> directly are sbuild-qemu-update and sbuild-qemu-boot that assist with updating
> or entering a qemu image for autopkgtest use, respectively.

Correct, sbuild-qemu needs a mapping from Debian arch to QEMU arch so
that when a user invokes

    $ sbuild-qemu --arch ppc64el *.dsc

sbuild-qemu knows which QEMU binary to request:
   amd64     needs   qemu-system-x86_64
   ppc64el   needs   qemu-system-ppc64le
   arm64     needs   qemu-system-aarch64
   etc.

That's all there is.

If there would be some system-wide solution for this (via symlinks or
whatever), great!


Side note: As Johannes indicated, sbuild-qemu is just a thin wrapper
around sbuild + autopkgtest. sbuild can use many backends and schroot is
the most popular, but the autopkgtest backend supports building in QEMU
VMs (autopkgtest-virt-qemu).

sbuild-qemu just makes this easy. It takes a minimal `sbuild-qemu`
invocation like the above, and adds all the magic incantations necessary
to get sbuild to use the autopkgtest-virt-qemu bridge.

In a similar vein, sbuild-qemu-create is just a convenience wrapper
around autopkgtest-build-qemu, for building the VM images in the first
place.

>>> So I think having symlinks would already be an improvement, but some places
>>> need access to the full mapping.
>>>
>>> Would you like me to open a new feature request bug on the BTS for this?
>>
>> Sure thing, - gimme the usage contexts, and we can cook something up.
>>
>> FWIW, I was thinking about either dropping qemu-system package (it is a meta-
>> package now) entirely, or combining different qemu-system-$arch back to single
>> qemu-system.  Most of the time you don't need whole list, just a single arch.
>>
>> For now, I'm not really sure we actually needs even the symlinks mentioned
>> above. This is just due to my misunderstanding, I guess.  For example, the
>> sbuild-qemu thing, - it needs not only the qemu-system-$arch binary naming
>> but also the package naming, it seems.
> 
> Ah you are referring to the Depends and Recomends of sbuild-qemu. Maybe this is
> a mistake. I'm not maintaining sbuild-qemu but Christian Kastner is, so they
> will be much more fit to answer all these questions. Putting them in CC. Maybe
> sbuild-qemu should Depend on the qemu-system meta-package to automatically pull
> in qemu-system-$foo for all possible architectures?
Perhaps I'm misunderstanding something, but the current setup of

   Depends: qemu-system-x86
   Recommends: qemu-system-arm, qemu-system-ppc

was chosen because those are the architectures supported by autopkgtest,
and thus by sbuild-qemu. There needs to be at least one qemu-system-* to
be useful, and x86 is the dominating arch.

But I'm totally open to adapting this in any way that might be more
convenient to you.

Best,
Christian