On Thu, Jun 14, 2012 at 05:24:49PM +0200, Alexander Kurtz wrote: > Thanks to multiarch, this is actually possible nowadays: > > $ dpkg --print-architecture > amd64 > $ file /usr/bin/hello > /usr/bin/hello: ELF 32-bit LSB executable, ARM, version 1 (SYSV), > dynamically linked (uses shared libs), for GNU/Linux 2.6.26, > BuildID[sha1]=0xa70889bfecf2965db6078601790c2cfdc34c146a, stripped > $ qemu-arm /usr/bin/hello > Hello, world! > $
Indeed! > This means that it is no longer necessary to keep foreign executables in > their own dedicated chroot. It would therefore be really great if you > could also include binfmt-support files in the qemu-user package and not > just in the qemu-user-static package. Yup, I've been giving this some thought recently... > The positive aspect is that this would greatly reduce the need to > install the statically compiled version. However, the downside is that > qemu-user and qemu-user-static would probably need to Conflicts: because > only one interpreter can be registered for any given binary format in > the kernel. > I think introducing a Conflicts: wouldn't matter since qemu-user-static > actually provides a superset of qemu-user (the only difference being the > ability to handle chroots) and there should be no need to have both > versions installed a the same time. Any thoughts? A Conflicts/Breaks would mean that qemu-user-static and the qemu metapackage wouldn't be installable at the same time, although you could manually install qemu-system separately, there are a few dependencies in the archive that should really depend on qemu-system (I mean to file more bugs about this). I've thought about making a separate qemu-binfmts package, that could register alternatives, so that qemu-arm-static or qemu-arm could register a symlink, say qemu-arm-binfmt, and then the binfmt files would register the qemu-arm-binfmt symlink. qemu-debootstrap would need to copy the appropriate qemu-FOO-static binary into the chroot as it does now and also create a symlink (or install it directly to the qemu-FOO-binfmt location). This would allow both qemu-user variants to be installable simultaneously. Also, splitting the binfmt handling from the qemu-user-static package would allow you to install the appropriate qemu-user or qemu-user-static package into the chroot, so that upgrades of the chroot would also be able to upgrade the qemu-user/qemu-user-static binaries. I'm not sure I could make this happen in time for wheezy's freeze, unfortunately... but was hoping to put some time into this during Debconf12. live well, vagrant -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
