[Gluster-devel] [Gluster-users] Dependency issue while installing glusterfs-3.6beta with vdsm

[Kaleb KEITHLEY]

On 10/30/2014 01:50 PM, Anders Blomdell wrote:
> On 2014-10-30 14:52, Kaleb KEITHLEY wrote:
>> On 10/30/2014 04:36 AM, Anders Blomdell wrote:
>>>
>>> I think a compat package would make the coupling between server and client
>>> looser, (i.e. one could run old clients on the same machine as a new server).
>>>
>>> Due to limited time and dependency on qemu on some of my testing machines, I
>>> still have not been able to test 3.6.0beta3. A -compat package would have helped
>>> me a lot (but maybe given you more bugs to fix :-)).
>>
>> Hi,
>>
>> Here's an experimental respin of 3.6.0beta3 with a -compat RPM.
>>
>> http://koji.fedoraproject.org/koji/taskinfo?taskID=7981431
>>
>> Please let us know how it works. The 3.6 release is coming very soon and if this works we'd like to include it in our Fedora and EPEL packages.
> Nope, does not work, since the running usr/lib/rpm/find-provides
> (or /usr/lib/rpm/redhat/find-provides) on the symlink does not
> yield the proper provides [which for my system should be
> "libgfapi.so.0()(64bit)"]. So no cigar :-(

Hi,

1) I erred on the symlink in the -compat RPM. It should have been 
/usr/lib64/libgfapi.so.0 -> libgfapi.so.7(.0.0).

2) find-provides is just a wrapper that greps the SO_NAME from the 
shared lib. And if you pass symlinks such as /usr/lib64/libgfapi.so.7 or 
/usr/lib64/libgfapi.so.0 to it, they both return the same result, i.e. 
the null string. The DSO run-time does not check that the SO_NAME matches.

I have a revised set of rpms with a correct symlink available 
http://koji.fedoraproject.org/koji/taskinfo?taskID=7984220. The main 
test (that I'm interested in) is whether qemu built against 3.5.x works 
with it or not.

>
> Have you checked my more heavyhanded http://review.gluster.org/9014 ?

I have. A) it's, well, heavy handed ;-) mainly due to, B) there's lot of 
duplicated code for no real purpose, and C) for whatever reason it's not 
making it through our smoke and regression tests (although I can't 
imagine how a new and otherwise unused library would break those.)

If it comes to it, I personally would rather take a different route and 
use versioned symbols in the library and not bump the SO_NAME. Because 
the old APIs are unchanged and all we've done is add new APIs.

But we're running out of time for the 3.6 release (which is already 
months overdue.)

I don't know if anyone here looked at doing versioned symbols before we 
made the decision to bump the SO_NAME. I've looked at Ulrich Dreppers 
https://software.intel.com/sites/default/files/m/a/1/e/dsohowto.pdf 
write-up and it's not very hard.

--

Kaleb