Ceph » devops

Some people complained about this when I synced up the fedora's spec file with the upstream one (especially the fact that /usr/lib64 gets created on i686). I don't think it is enough just to not create the symlink in these releases though. It would be nice to cleanup the mess, too. Hence, eventually I created this patch to fix it for fedora:

...
@@ -686,8 +686,17 @@ fi

 %post -n librbd1
 /sbin/ldconfig
+# First, cleanup
+rm -f /usr/lib64/qemu/librbd.so.1
+rmdir /usr/lib64/qemu 2>/dev/null || true
+rmdir /usr/lib64/ 2>/dev/null || true
+# If x86_64 and rhel6+, link the library to /usr/lib64/qemu -- rhel hack
+%ifarch x86_64
+%if 0%{?rhel} >= 6
 mkdir -p /usr/lib64/qemu/
 ln -sf %{_libdir}/librbd.so.1 /usr/lib64/qemu/librbd.so.1
+%endif
+%endif

 %postun -n librbd1
 /sbin/ldconfig
...

This ticket is inaccurate.

The version of qemu-kvm that ships with base RHEL 6.x or 7.x does not and has no plans to work with librbd through the dynamic linking.

As such, we still need to provide the symlink for users who install the custom qemu-kvm built by the Ceph community over their RHEL or CentOS install. This was the purpose of the symlink creation in the first place.

For qemu-kvm-rhev, now that librbd will be in the base RHEL distro, they can do a build time link to librbd so the symlink is not needed for them, but it probably makes sense to leave it just so we don't have to manage separate builds upstream.

As it turns out, qemu-kvm in RHEL 7.1 Base does build-time link against librbd1. So in theory the symlink is only needed for RHEL 6.