[Gluster-devel] RPM re-structuring

Anand Avati anand.avati at gmail.com
Wed Aug 14 09:03:15 UTC 2013


On Wed, Aug 14, 2013 at 1:54 AM, Harshavardhana
<harsha at harshavardhana.net>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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20130814/db7c197f/attachment-0001.html>


More information about the Gluster-devel mailing list