[fedora-virt] QEMU new Package

[Daniel P. Berrange]

On Tue, Feb 03, 2009 at 10:34:12PM +0000, Mark McLoughlin wrote:
> (cc-ed a few people who were interested on irc)
> 
> On Tue, 2009-02-03 at 18:11 -0200, Glauber Costa wrote:
> > Hi guys.
> > 
> > I've built a qemu image in here:
> > 
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151
> > 
> > It contains the basic work to get qemu package updated. Basically,
> > we're talking about getting the qemu code from svn and creating multiple
> > packages, so one could grab just the architecture of interest.
> > Todo, is the creation of a meta-package to grab'em all at once.
> 
> Okay, so this adds ~30 sub-packages. In retrospect, maybe ajax and co.
> have a point saying that's a bit excessive :-)
> 
> One downside to so many sub-packages is that it means the total size of
> the RPMs is ~15Mb instead of ~10Mb.
> 
> The on-disk size of the current qemu package is ~50Mb. What most people
> care about is /usr/bin/qemu (and in future qemu-kvm). Those bits only
> have a ~3Mb on-disk size. Each other target adds ~1.5Mb.
> 
> How about splitting it this way:
> 
>   qemu:
>     - /usr/bin/qemu
>     - /usr/bin/qemu-system-x86_64 (only on x86_64, obviously)

Err, qemu-system-x86_64 exists just fine on 32-bit hosts.

>     - qemu-kvm

This should go away altogether I hope. Until it does, just
keeping it whereever the x86 emulators are should be fine.

>     - qemu-nbd

This one should be separate, since it is generally useful
even without any of the emulators - eg by Xen, or anyone
else wishing a nbd client for disk images.

>     - docs
>     - BIOSes
>     - keymaps
>     - init script
> 
>   qemu-img
>     - /usr/bin/qemu-img
> 
>   qemu-system:
> 
>     - qemu-system-arm
>     - qemu-system-cris
>     - qemu-system-i386

What's this for ?  'qemu' is always i386, and that shouldn;t
be changed because far too much assumes 'qemu' is always the
i386 binary.

>     - qemu-system-m68k
>     - qemu-system-mips
>     - qemu-system-mips64
>     - qemu-system-mips64el
>     - qemu-system-mipsel
>     - qemu-system-ppc
>     - qemu-system-ppc64
>     - qemu-system-ppcemb
>     - qemu-system-sh4
>     - qemu-system-sh4eb
>     - qemu-system-sparc

Why not group them into related sets. eg, all PPC
variants in one package, all the 'sh' variants,
and all the 'mips' variants, and all x86 variants.
That'd compress the # of sub-RPMS to a small handful

   qemu-system-x86
   qemu-system-mips
   qemu-system-sh
   qemu-system-ppc
   qemu-system-sparc
   qemu-system-68k

>   qemu-linux:
> 
>     - qemu-alpha
>     - qemu-arm
>     - qemu-armeb
>     - qemu-cris
>     - qemu-debuginfo
>     - qemu-i386
>     - qemu-m68k
>     - qemu-mips
>     - qemu-mipsel
>     - qemu-ppc
>     - qemu-ppc64
>     - qemu-ppc64abi32
>     - qemu-sh4
>     - qemu-sh4eb
>     - qemu-sparc
>     - qemu-sparc32plus
>     - qemu-sparc64
>     - qemu-x86_64

This seems reasonable - judging by how broken most of these
are, I find it hard to believe they're used much, so having
them in one sub-RPM ought to be fine.

> One thing I don't like too much about that is if you do a yum update
> from the current package you lose all the stuff in qemu-system and
> qemu-linux. I doubt that would cause anyone trouble in practice, though.

Just keep 'qemu' as a meta-package pulling in all the sub-RPMs. 

People who only want the x86 bits will probably going from a starting
point of having the 'kvm' RPM installed. If we make system-system-x86
sub-RPM replace+obsolete 'kvm', then updates from people who just have
KVM will keep a lightweight install, and those who have the full QEMU
stack will not be broken either.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|