On the qemu-system-XXX packages

Richard W.M. Jones rjones at redhat.com
Tue Jan 7 13:08:26 UTC 2014


On Mon, Jan 06, 2014 at 11:54:01PM +0100, Mauricio Tavares wrote:
>       It seems a lot of them were not created for EPEL 6 and 7 (see
> https://apps.fedoraproject.org/packages/qemu-system-arm as an
> example). I take that means the current maintainer is up to his nose
> in projects. How can I be equal parts lazy ass and selfish SOB and
> volunteer to be a co-maintainer to that family of packages?

https://fedoraproject.org/wiki/Join_the_package_collection_maintainers?rd=PackageMaintainers/Join

However ...  you have picked possibly the most complex package in
EPEL.  Read on.

[This covers a lot of Red Hat Enterprise Linux specific details, but
they are IMHO necessary to understand what's going on in EPEL.]

- Qemu ships in base RHEL >= 5.4

- It might not be called qemu.  In RHEL 6 it's called 'qemu-kvm' (for
no particularly good reason).

- qemu-kvm in RHEL removes a lot of features which we (Red Hat) don't
believe are stable enough for our customers to use.  Not just whole
binaries like qemu-system-arm, but many emulated devices and block
device drivers.

- qemu-kvm in RHEL (6+) moves qemu binaries to /usr/libexec because
Red Hat's customers are not supposed to run it directly (but use it
via libvirt).

- EPEL has a policy about shipping packages that are also present in
RHEL (or upgrading packages which are in RHEL), which is that it
shouldn't be done:

https://fedoraproject.org/wiki/EPEL/FAQ#Does_EPEL_replace_packages_provided_within_Red_Hat_Enterprise_Linux_or_layered_products.3F
https://fedoraproject.org/wiki/EPEL/FAQ#How_can_I_know_which_packages_are_part_of_RHEL.3F

However EPEL 5 & 6 has an (outdated) package called 'qemu'.  Obviously
that's not called 'qemu-kvm' so it's not strictly breaking any
policies ... and maybe we *should* break the policy in this case.

The current 'qemu' package in EPEL 6 coexists with 'qemu-kvm' by
having a different name and putting binaries in a different place.
(Not sure which binaries libvirt will use.)  However it's a messy
situation, so tread carefully.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)


More information about the devel mailing list