[fedora-virt] QEMU new Package

Wed Feb 4 15:15:00 UTC 2009

On Wed, Feb 04, 2009 at 08:41:56AM +0000, Mark McLoughlin wrote:
> 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:
I believe qemu-user suits better upstream name usage. Other than that,
I think this proposal is sound.

Also, there has been a proposal by ajax in #fedora-devel to have a "qemu-native"
package, that would install native emu/virt for whatever architecture you're running at.

What do you guys think of this? 