Re: RFC: Rearranging qemu-system packages
19.04.2023 11:41, Christian Ehrhardt пишет:
On Wed, Apr 19, 2023 at 8:47 AM Michael Tokarev <mjt@tls.msk.ru> wrote:
..
But while I see the appeal of reunifying I also have often liked (and
seen people appreciate and use) this being split and explicit.
Do you consider your proposed qemu-system-native be a meta package
that depends on the right qemu-system-$arch, or an actual package with
content.
So would it be:
a)
x86: qemu-system-native -dep-> qemu-system-x86_64
ppc: qemu-system-native -dep-> qemu-system-ppc
or
b)
x86: qemu-system-native
ppc: qemu-system-native
I thought about the b) case, not a). kvm is the most interesting
use case (esp. on x86), and that's your -s390x package is about,
too, - so native-kvm qemu is free from the rest of -emu parts.
The idea is to have two binay packages, like -native and -emu,
with -native being for this architecture, with the rest being
in -emu. This way we don't have many packages, but still will
be able to optimize for the most important and often use case.
Splitting it all into individual qemu-system-x86-64, qemu-system-i386,
qemu-system-loongson64 etc (so -native becomes just a Provides or
a dummy dep-only pkg) seems to be too much. I dislike so many small
packages, and multiple binaries in the same .tar compresses way
better :)
I personally like (a) more to simplify dependencies while not breaking habits.
But that might be just me, so I wanted to ask for clarification so
everyone is on the same page here.
The simplest way with deps is to merge everything into a single
qemu-system. But it is somewhat huge. Maybe we'll be able to
shrink it quite a bit by using a common shared lib for common
parts (large portion in the executables is the same), but that
requires quite some work. And this is definitely a way to go
if upstream will merge whole thing into a single binary.
Speaking of deps simplification, in 8.0 I provided qemu-system-${DEB_HOST_ARCH}
variants for all qemu-system-foo packages (I think I mentioned this
already).
I also want to provide qemu-system-for-host (meta)package, to
simplify build-deps for cross-compilation cases, - that aim to
provide build-native qemu-system executable for the build-host
target (it is not the same as qemu-system-native mentioned above).
/mjt
Reply to: