<div dir="ltr">On Wed, Aug 14, 2013 at 1:54 AM, Harshavardhana <span dir="ltr"><<a href="mailto:harsha@harshavardhana.net" target="_blank">harsha@harshavardhana.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><br><div><br></div></div></div><div>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.</div>
<div>
<div><br></div></div></div></div></div></blockquote><div><br></div></div><div>rpm uses 'ldd' command to get dependencies for 'glusterfs-api' to 'glusterfs-libs' - automatically. You don't need a forced specification.</div>
<div><br></div><div>Specifying runtime time dependency is done this way </div><div><br></div><div><div>%package api</div><div>Summary: Clustered file-system api library</div><div>Group: System Environment/Daemons</div>
<div>Requires: %{name} = %{version}-%{release} -----------> Install-time dependency. </div></div><div class="im"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> 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)<br></div></blockquote><div><br></div></div><div>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?</div>
<span><font color="#888888">
</font></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div bgcolor="#FFFFFF" text="#000000">
<br></div></div></blockquote></div></div></div></blockquote><div><br></div></div><div>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? </div>
</div></div></div></blockquote><div><br></div><div>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. </div>
</div></div></div>