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

[Anders Blomdell]

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


> 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.

>> 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).

> 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.


> 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?

-- 
Anders Blomdell                  Email: anders.blomdell at control.lth.se
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden