On Mon, Jan 21, 2013 at 10:58:48PM +0400, Michael Tokarev wrote: > We in debian talked about splitting qemu-system into > individual target packages for a long time, and there's > a patch (almost current) to support it, in qemu-system-split-mjt > branch of qemu debian git tree (I'll refresh it hopefully > today). > > I think it's time to decide whenever we want to do that > or not. > > The idea is to provide qemu-system-x86, qemu-system-arm, > etc, together with qemu-system-common (with common files > if any), and qemu-system-misc for "miscellaneous" arches > for which there was no separate package introduced. > > It was a long way there, and I'm still not certain if > we really want to do that or not, but the current > qemu-system is huge and has many non-trivial dependencies > (various firmwares).
FWIW, we had the same thoughts in Fedora a few years back. In the end, we stopped short of creating one package per system target. Instead we went for one package per "architecture family" where a family includes both the 32-bit & 64-bit variants. eg qemu-system-x86 contains i686 & x86_64 emulators. This level of granularity helped keep the number of packages reasonably sane. We left all the userspace emulators in one package on the grounds that their userbase is tiny and probably don't care. We had a qemu-common for some shared pieces, and qemu-img so that tools can get hold of the qemu-img binary without pulling in any of the virtualization pieces. You can see what we ended up with here: http://kojipkgs.fedoraproject.org/packages/qemu/1.3.0/4.fc19/x86_64/ http://pkgs.fedoraproject.org/cgit/qemu.git/tree/qemu.spec > Second, it isn't clear how -dbg packages should be handled. > It is sometimes useful to have them, -- should we have one > huge pkg with all debug info which breaks all qemu-system-* > of "wrong" version, or should we have one dbg per target? > And again, the size (or count of packages) is large. IMHO one debug package is sufficient - it is reasonable to assume that if multiple qemu-system-* packages are installed, they would all be the same version. > At least, when refreshing the branch (note it is volatile, > ie, I rebase it on top of debian-experimental currently), > I'll add Provides: qemu-system-$arch for all qemu-system-target, > so that it will be possible for other packages to depend on > particular arch they're interested, not whole qemu-system. > And add this to current 1.3 branch as well. We also added a virtual 'qemu-kvm' package which depends on the particular qemu-system-* package which has KVM support enabled for that host arch. This lets apps depend on 'qemu-kvm' without having to do different deps depending on the architectures they are built on. > Comments? I think it'd be a good move to split up the large qemu-system package into something smaller. It is very rare to have someone who genuinely wants to have all the emulators installed at once. In the server / desktop virt world, probably the vast majority of people only care about having the particular qemu-system-* emulators which contain KVM support. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
