[Gluster-devel] RPM re-structuring
Harshavardhana
harsha at harshavardhana.net
Wed Aug 14 08:54:10 UTC 2013
>
>
>
> 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*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20130814/20a102ab/attachment-0001.html>
More information about the Gluster-devel
mailing list