Re: [Gluster-devel] RPM re-structuring

[Anand Avati]

On Wed, Aug 14, 2013 at 1:54 AM, Harshavardhana <address@hidden> wrote:

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? 

This would solve your version of the problem. But the original concern raised was that the whole shebang of glusterfs translators and transports get installed for someone who wants libvirt/qemu and doesn't care what glusterfs even is. Your version of the problem is in direct contradiction with the initially reported problem for which the restructuring was proposed.