On 2014-10-30 22:06, Kaleb KEITHLEY wrote: > 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. A looked/tried at the wrong RPM > >> >> >>> 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? Me :-( (putting files in the wrong location) Unfortunately hard to test, my libvirtd (1.1.3.6) seems to lack gluster support (even though qemu is linked against libvirtd), any recommended version of libvirtd to compile? >>>> 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. OK, no problems there then. > >> >>> 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.) So is my testing, hope I'm not the bottleneck here :-) >>> >>> 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. +2 /Anders -- 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
