https://bugzilla.redhat.com/show_bug.cgi?id=1080583
--- Comment #19 from Darryl L. Pierce dpierce@redhat.com --- (In reply to Mukundan Ragavan from comment #18)
---> obsoletes fixed.
- $ rpmls compat-qpid-cpp-client-0.24-7.fc21.x86_64.rpm
[ ... ] -rwxr-xr-x /usr/lib64/libqpidtypes.so.1.0.0 drwxr-xr-x /usr/lib64/qpid drwxr-xr-x /usr/lib64/qpid/client drwxr-xr-x /usr/share/doc/compat-qpid-cpp-client -rw-r--r-- /usr/share/doc/compat-qpid-cpp-client/DESIGN [ ... ]
---> So, qpid directories ownerships are fine.
---> -ha issue seems reasonable to me.
- compat-qpid-cpp-server-store.x86_64: W: dangling-relative-symlink
/usr/lib64/qpid/daemon/store.so store.so.0.24
---> store.so.0.24 is part of server which is a dependency. So, this is fine.
====================================================
Could you please clarify the following -
- compat-qpid-cpp-server-ha.x86_64: E: subsys-not-used
/etc/rc.d/init.d/qpidd-primary
No lock file?
The file uses the same lockfile as /etc/rc.d/init.d/qpidd. This particular script is for starting up the primary broker in a cluster, so you can't run both it and qpidd at the same time. Hence the single lock file between them.
- Lastly, there is this unversioned -so files not in a devel package.
Unversioned so-files
compat-qpid-cpp-server: /usr/lib64/qpid/daemon/ha.so compat-qpid-cpp-server: /usr/lib64/qpid/daemon/legacystore.so compat-qpid-cpp-server: /usr/lib64/qpid/daemon/store.so compat-qpid-cpp-server: /usr/lib64/qpid/daemon/xml.so compat-qpid-cpp-server-ha: /usr/lib64/qpid/daemon/ha.so compat-qpid-cpp-client-rdma: /usr/lib64/librdmawrap.so compat-qpid-cpp-client-rdma: /usr/lib64/qpid/client/rdmaconnector.so compat-qpid-cpp-server-rdma: /usr/lib64/qpid/daemon/rdma.so compat-qpid-cpp-server-xml: /usr/lib64/qpid/daemon/xml.so compat-qpid-cpp-server-store: /usr/lib64/qpid/daemon/store.so
They're not development libraries (which is why they're not public) but are plugins to for the broker and the client libraries. That's why they all live in the qpid subdirectory (except rdmawrap, which should be in the qpid directory, so I'll file a bug upstream to fix that install location).