qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] qemu-system split


From: Michael Tokarev
Subject: [Qemu-devel] qemu-system split
Date: Mon, 21 Jan 2013 22:58:48 +0400
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/17.0 Icedove/17.0

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

3 things which stopped me from doing this so far (besides
the wheezy freeze - I wanted to do that after freeze, but
no I don't think it is relevant anymore).

First is the amount of new packages we introduce.  Dunno if
one huge package is worse or better than a lot of small
packages.  Here's the deal:

qemu-kvm:i386 1.1.2:
 Installed-Size: 4756
 Depends: seabios, vgabios, ipxe

qemu-system:i386 1.3.0:
 Installed-Size: 89232
 Depends: seabios, vgabios, ipxe, openbios-ppc, openbios-sparc, openhackware, 
libxen, ...

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.

And 3rd, the qemu-system-misc thing - I wasn't clear for me
how to handle targets going in/out of this package - I mean
transitions, what to do when we'll want to split one arch
out of -misc.

This last one is - in my opinion - the most important one:
transitions.  And I don't really know how to do that in a
nice and clean way...

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.

Comments?

Thanks,

/mjt



reply via email to

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