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@xxxxxxxxxxxxxx Department of Automatic Control Lund University Phone: +46 46 222 4625 P.O. Box 118 Fax: +46 46 138118 SE-221 00 Lund, Sweden _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
