qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] qemu-system split


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] qemu-system split
Date: Mon, 21 Jan 2013 19:43:49 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

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 :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]