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
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
