Quoting Michael Tokarev (2022-12-25 08:01:31) > >> What do you think it should be used for? Maybe there's no need for a > >> mapping to begin with, maybe qemu packages can provide symlinks with the > >> right naming? > > > > yes, most places (like /usr/share/devscripts/scripts/run_bisect_qemu) use it > > exclusively to figure out the qemu-system-XXX binary to run for a specific > > Debian architecture, but: > > > > - mmdebstrap for example also uses it to guess the right > > /proc/sys/fs/binfmt_misc/qemu-XXX directory > > What it is used for? mmdebstrap checks for the F flag in /proc/sys/fs/binfmt_misc/qemu-XXX to make sure that it doesn't have to copy the qemu-user-static binary into the chroot. > > - /usr/share/autopkgtest/lib/autopkgtest_qemu.py also needs the full list of > > available qemu-system-XXX binaries > > Why? :) the script tries to guess the qemu architecture from the commandline that the user can optionally pass to autopkgtest-virt-qemu. It does so, by maintaining a reverse mapping table listing all known qemu-system-XXX commands. > > - /usr/bin/sbuild-qemu needs the full list of available arches to show the > > user the options that they can choose from > > 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. > > 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? Thanks! cheers, josch
Attachment:
signature.asc
Description: signature