On Tue, 15 Apr 2014 09:18:27 Michael Tokarev wrote: > This approach works, but, as you've shown below, not for ceph, because > ceph does not tolerate mixed-cluster, so once you update any 3rd party, > not cluster-related but cluster-used, software, you'll have to upgrade > whole cluster too, because according to the package manager, you'll > have to update - in this case - librbd to the latest, which will most > likely require updating whole ceph stack on one node, which ofcourse > requires upgrading ceph stack on other nodes as well.
I only meant that different versions of cluster components (in my short
experience with 0.72.2 and 0.78) do not work well with each other.
Having said that `qemu-img` linked with "librbd-0.72.2" worked well with
cluster 0.72.2 and with 0.78 (unless there are some subtle bugs that I didn't
notice).
> Dmitry: this is a good example of why naive `makeshlibs -V' approach
> sometimes should NOT be used...
I see your point. Indeed .symbols approach to linking is more flexible.
However I believe that `makeshlibs -V' is the safest and most conservative way
to ensure that application will always require at least the very version of
the library it was build with (and not earlier). Basically I have two
arguments for this: easier maintenance (here my only concerns are C++ symbols
as maintaining C symbols is easy) and run-time safety. To my taste there were
way too many bugs in 0.72.2 to use it with confidence. Even if combination of
client librbd/librados-0.72.2 libraries *may* work with newer cluster just
fine, I'd rather not take any chances and force upgrading all client libraries
just to be safe even if it may be unnecessary.
I'm sure some time later symbols will work just fine to allow linking with
older client libraries.
I'm already gaining more confidence with 0.79 than I ever had with 0.72.2 so I
hope we will start using symbols soon if it won't cause any build problems in
"experimental".
> For now, I think, the current approach taken by Dmitry is the best:
> he gave all C symbols a version, so that any non-C++ program will
> use the versioned .symbols file correctly. And marked all C++ symbols
> as belonging to "current" version (I think it should be possible to
> use a variable in .symbols file, like ${VERSION}, somehow) -- so that
> all C++ users of the library will always require "latest" version.
> We don't have many C++ users in Debian archive (if at all), so this
> should not be that bad as a start. Later on, when the above changes
> will land in ceph, it will be possible to expand the C++ regex in
> the symbols file to include actual list of exported symbols.
Thank you very much for reassuring me with the chosen strategy.
By the way today I've made another commit to "experimental" branch to update
symbols files with data from 0.72.2. I doubt if including older symbols would
be necessary...
--
All the best,
Dmitry Smirnov
GPG key : 4096R/53968D1B
signature.asc
Description: This is a digitally signed message part.
