[fedora-virt] QEMU new Package

[Mark McLoughlin]

On Tue, 2009-02-03 at 22:44 +0000, Daniel P. Berrange wrote:
> 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.

Yeah, what I was getting at was that the qemu package would only contain
an emulator for the native architecture. So, qemu wouldn't contain the
x86_64 emulator on 32 bit.

That was when I thought /usr/bin/qemu was just a hardlink to the native
system emulator.

Now that I see that /usr/bin/qemu is always i386 (even on e.g. ppc), I
don't like this idea of the base package containing just the native
emulator so much anymore.

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

Yep.

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

Agree, but I'd be inclined not to bother until someone actually wants
it.

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

Right, my mistake - the name was just taken from glommer's proposed
qemu-system-i386 package which would contain /usr/bin/qemu.

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

Sounds reasonable enough.

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

Yeah, sounds good.

So, in summary:

  qemu-img
    - /usr/bin/qemu-img

  qemu-common:
    - /usr/bin/qemu-nbd
    - docs
    - BIOSes
    - keymaps
    - init script

  qemu-system-x86:
    - /usr/bin/qemu
    - qemu-system-x86_64
    - /usr/bin/qemu-kvm

  qemu-system-arm:
    - qemu-system-arm

  qemu-system-cris:
    - qemu-system-cris

  qemu-system-m68k
    - qemu-system-m68k

  qemu-system-mips
    - qemu-system-mips
    - qemu-system-mips64
    - qemu-system-mips64el
    - qemu-system-mipsel

  qemu-system-ppc 
    - qemu-system-ppc
    - qemu-system-ppc64
    - qemu-system-ppcemb

  qemu-system-sh
    - qemu-system-sh4
    - qemu-system-sh4eb

  qemu-system-sparc
    - qemu-system-sparc

  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

  qemu:
    - meta package requiring all sub-packages

Cheers,
Mark.