Description of problem: While trying to remove gluster packages from Fedora 22 system it shows dependency on qemu, libvirt and boxes. Version-Release number of selected component (if applicable): Fedora release 22 How reproducible: # rpm -qa | grep gluster glusterfs-cli-3.6.3-3.fc22.x86_64 glusterfs-libs-3.6.3-3.fc22.x86_64 glusterfs-api-3.6.3-3.fc22.x86_64 glusterfs-3.6.3-3.fc22.x86_64 glusterfs-fuse-3.6.3-3.fc22.x86_64 glusterfs-server-3.6.3-3.fc22.x86_64 # # yum erase `rpm -qa | grep gluster` Yum command has been deprecated, redirecting to '/usr/bin/dnf erase glusterfs-cli-3.6.3-3.fc22.x86_64 glusterfs-libs-3.6.3-3.fc22.x86_64 glusterfs-api-3.6.3-3.fc22.x86_64 glusterfs-3.6.3-3.fc22.x86_64 glusterfs-fuse-3.6.3-3.fc22.x86_64 glusterfs-server-3.6.3-3.fc22.x86_64'. See 'man dnf' and 'man yum2dnf' for more information. To transfer transaction metadata from yum to DNF, run: 'dnf install python-dnf-plugins-extras-migrate && dnf-2 migrate' Dependencies resolved. ============================================================================================================================== Package Arch Version Repository Size ============================================================================================================================== Removing: glusterfs x86_64 3.6.3-3.fc22 @System 5.1 M glusterfs-api x86_64 3.6.3-3.fc22 @System 117 k glusterfs-cli x86_64 3.6.3-3.fc22 @System 385 k glusterfs-fuse x86_64 3.6.3-3.fc22 @System 225 k glusterfs-libs x86_64 3.6.3-3.fc22 @System 884 k glusterfs-server x86_64 3.6.3-3.fc22 @System 2.3 M gnome-boxes x86_64 3.16.2-3.fc22 @System 4.5 M libvirt x86_64 1.2.13.1-2.fc22 @System 0 libvirt-daemon-driver-qemu x86_64 1.2.13.1-2.fc22 @System 1.2 M libvirt-daemon-driver-storage x86_64 1.2.13.1-2.fc22 @System 540 k libvirt-daemon-kvm x86_64 1.2.13.1-2.fc22 @System 0 qemu-img x86_64 2:2.3.0-5.fc22 @System 2.9 M qemu-kvm x86_64 2:2.3.0-5.fc22 @System 0 qemu-system-x86 x86_64 2:2.3.0-5.fc22 @System 13 M Transaction Summary ============================================================================================================================== Remove 14 Packages Installed size: 32 M Is this ok [y/N]: N Operation aborted. Steps to Reproduce: 1. list gluster packages installed 2. try to remove gluster packages 3. It shows dependencies on qemu, libvirt and boxes Actual results: shows dependencies on qemu,libvirt and box Expected results: There should not be any dependency on qemu,libvirt..It should remove only gluster related packages. Additional info:
qemu links against libgfapi.so from the glusterfs-api package. This makes it possible to support storage directly on Gluster volumes without the need to mount the volume, like "qemu ... -drive gluster://server/volume/vm.img ...". The dependency is the other way around, qemu depends on glusterfs-api, and if glusterfs-api gets uninstalled, qemu gets pulled with it. The same is true for installing qemu, glusterfs-api is a requirement and will get installed too. Some other projects that use libgfapi.so implement a plugin functionality (see Samba, NFS-Ganesha). This makes it possible to only install the plugins (and dependencies) that a user wants. For all I know, qemu does not offer the option for dynamically loaded plugins :-/ Moving this to the qemu component so that the maintainers can share their thoughts.
Thanks Niels. <<The same is true for installing qemu, glusterfs-api is a requirement and will get installed too. If I am "not" interested in using glusterfs in qemu, should installing qemu still install glusterfs-api too? I think it is wrong. There is too much of inter-dependencies created here.
qemu does have support for block driver modules, so we could make the gluster dep a subpackage. But I never did it since libvirt storage support _also_ has a dep on gluster, which can't be modularized. So most qemu/kvm users wouldn't really benefit since they are likely using libvirt anyways. But I'll add it to the todo list to investigate again
(In reply to Cole Robinson from comment #3) > qemu does have support for block driver modules, so we could make the > gluster dep a subpackage. But I never did it since libvirt storage support > _also_ has a dep on gluster, which can't be modularized. So most qemu/kvm > users wouldn't really benefit since they are likely using libvirt anyways. > But I'll add it to the todo list to investigate again Thanks Cole! If somebody wishes to upgrade/remove glusterfs. They need to remove qemu,libvirt, boxes even if they are NOT using these packages. My humble request is to make the dependency ONLY if there is a need.
As mentioned, the libvirt/boxes dep issue will take substantially more work... we need dynamic modules for libvirt's storage support.
I opened an upstream libvirt bug to track that work: https://bugzilla.redhat.com/show_bug.cgi?id=1243001
cc'ing Vijay Bellur. I agree (bz 1194503), KVM should NOT have any hard dependency on Gluster being present, but should be able to utilize it (for libgfapi, for example), if it is present. That's why we have dynamically loadable shared libraries. This is consistent with creating leaner, smaller, less complicated Linux installs. We don't want to blow away running VMs that depend on Gluster by uninstalling Gluster, but it's not hard to tell whether there are such VMs running - they would have disks in their libvirt XML that reference libgfapi, yes?
Still relevant with f24
Fedora 25+ now has qemu block drivers built as modules. qemu-system-x86 will still pull in gluster via qemu-block-gluster, but you can use the qemu-system-x86-core package to pull in qemu without any external block drivers.