Re: [Gluster-devel] RPM re-structuring

[Harshavardhana]

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