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

[Kaleb KEITHLEY]

On 10/30/2014 04:34 PM, Anders Blomdell wrote:
> On 2014-10-30 20:55, Kaleb KEITHLEY wrote:
>> 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).
> Noticed that, not the main problem though :-)
>
>> 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.
>
> No, but yum checks for "libgfapi.so.0()(64bit) / libgfapi.so.0", so
> i think something like this is needed for yum to cope with upgrades.
>
> %ifarch x86_64
> Provides:         libgfapi.so.0()(64bit)
> %else
> Provides:         libgfapi.so.0
> %endif


That's already in the glusterfs-api-compat RPM that I sent you. The 
64-bit part anyway. Yes, a complete fix would include the 32-bit too.

>
>
>> 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.
> First thing is to get a yum upgrade to succeed.

What was the error?


>
>>> 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
> Agreed, quick fix to avoid soname hell (and me being unsure of
> what problems __THROW could give rise to).

In C, that's a no-op. In C++, it tells the compiler that the function 
does not throw exceptions and can optimize accordingly.

>
>> 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.)
> Me neither, but I'm good at getting smoke :-)
>
>> 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.
> I guess we have passed that point since 3.6.0 is out in the wild (RHEL),
> and no way to bump down the version number.

That's RHS-Gluster, not community gluster. There's been some discussion 
of not packaging 3.6.0 and releasing and packaging 3.6.1 in short order. 
We might have a small window of opportunity. (Because there's never time 
to do it right the first time, but there's always time to do it over. ;-)

>
>
>> 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.
> Too late now, though?

Perhaps not.

--

Kaleb