On Tue, Jan 8, 2019 at 9:42 PM Jason Dillaman <jdillama@xxxxxxxxxx> wrote: > > On Tue, Jan 8, 2019 at 6:26 AM kefu chai <tchaikov@xxxxxxxxx> wrote: > > > > On Tue, Jan 8, 2019 at 9:27 AM Jason Dillaman <jdillama@xxxxxxxxxx> wrote: > > > > > > Apologies for resurrecting this thread, but do have a plan forward for > > > QEMU's librados2 dependencies post-Nautilus upgrade? Do we need to > > > create a librados2-compat RPM/DEB that has a dummy librados2 library? > > > > Jason, thanks for raising this concern. yeah, i think we should offer > > an upgrade path for QEMU and probably other existing librados2's C API > > consumers, i will try to whip up a librados2-compat package before > > nautilus rolls out. > > Thanks. Let me know if you need / want help. > Jason, i just realized that you are talking about runtime compatibility instead of built-time compatibility. i thought it was something like libmariadbclient-dev-compat [0], which provides symbolic links like /usr/lib/x86_64-linux-gnu/libmariadbclient.so <= /usr/lib/x86_64-linux-gnu/libmysqlclient.so but apparently, librados2-compat is not a dev package. and we does offer librados.so so the existing librados2 application can compile just fine with the new librados-dev package. so presumably, you are suggesting a package which offers a just-enough librados.so.2 which wraps (or even links to!) librados.so.3. and just like its predecessor, this new librados.so.2 will work with QEMU compiling against the old librados-dev. am i right? but this approach is a little bit controversial, IMHO. as we'd shipping a librados2 which is not strictly backward compatible to librados2 API. so back to your question, i don't see the need to provide the runtime-compatible package for existing librados2 clients. --- [0] https://packages.debian.org/sid/libmariadbclient-dev-compat -- Regards Kefu Chai
