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?
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
- 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
- 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:
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.
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