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.