Why does so much virt stuff depend on glusterfs?

[Richard W.M. Jones]

On Wed, Jul 24, 2013 at 10:17:14AM +0100, Daniel P. Berrange wrote:
> On Tue, Jul 23, 2013 at 09:46:30PM +0100, Richard W.M. Jones wrote:
> > On Tue, Jul 23, 2013 at 03:00:46PM -0400, Bill Nottingham wrote:
> > > Richard W.M. Jones (rjones at redhat.com) said: 
> > > > On Tue, Jul 23, 2013 at 06:15:32PM +0100, Richard W.M. Jones wrote:
> > > > > However for some reason I can't quite understand, libvirt-daemon
> > > > > depends on 'qemu'.  That may be a bug?
> > > > 
> > > > I meant to write: "'libvirt-daemon-qemu' depends on 'qemu'".
> > > 
> > > Isn't it simplest for that to depend on a virtual 'qemu-system', which is
> > > provided by qemu-kvm on KVM arches, and qemu-system-XYZ on non-KVM arches?
> > 
> > Right, which is why I said this may be a bug.  Dan Berrange (CC'd on
> > this subthread) will know.
> 
> The libvirt-daemon-qemu package is intended to pull in the QEMU emulators.
> If you only want to pull in KVM, then you should depend on the separate
> libvirt-daemon-kvm package instead.

In libguestfs I have:

  Requires:      libvirt-daemon-qemu >= 0.10.2-3
  %ifarch %{ix86} x86_64
  Requires:      libvirt-daemon-kvm >= 0.10.2-3
  %endif

because I don't know if I'm going to be needing TCG or can use KVM.

Although, qemu-kvm is now an empty package ..  So all I really want is
qemu-system-%{arch}.

There's also code in libguestfs (src/launch-libvirt.c:parse_capabilities)
to parse the capabilities output looking for qemu or kvm.  It would be
nice if there was a "best" option instead.

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