Actually this *wasnt* what we discussed. glusterfs-api was supposed to depend on glusterfs-libs *ONLY*. This is because it has a linking (hard) relationship with glusterfs-libs, and glusterfs.rpm is only a run-time dependency - everything here is dlopen()ed.
rpm uses 'ldd' command to get dependencies for 'glusterfs-api' to 'glusterfs-libs' - automatically. You don't need a forced specification.
Specifying runtime time dependency is done this way
%package api
Summary: Clustered file-system api library
Group: System Environment/Daemons
Requires: %{name} = %{version}-%{release} -----------> Install-time dependency.
Just allowing qemu to execute by way of installing-libs and -api only won't help, since once qemu executes and someone tries qemu w/ gluster backend.. things will fail unless User has installed glusterfs rpm (which has all the client xlators)I think this was exactly what we concluded. That a user would need to install glusterfs rpm if they wanted to store VM images on gluster (independent of the fact that qemu was linked with glusterfs-api). Do you see a problem with this?
The problem here is user awareness - it generates additional cycles of communication. In this case 'qemu' should have a direct dependency on 'glusterfs.rpm' and 'glusterfs-api' when provided with "gfapi support" - wouldn't this solve the problem?
--
Religious confuse piety with mere ritual, the virtuous confuse regulation with outcomes
