Bug 474614

Related bug: #474613 (with a solution for the qpidd-* and rhm directory ownership)

Directory ownership problems:

 * the qpidd package owns the directory  %{_libdir}/qpidd  but this directory
   appears to be unused: the qpidd-{xml,acl,...} and the rhm rpms install their
   libraries in the directory %{_libdir}/qpid/daemon 

 * the qpidc-{ssl,rdma} rpms install libraries in the  %{_libdir}/qpid/client 
   directory which no package owns

A possible solution could be:

 * directory %{_libdir}/qpid/daemon --> should be owned by the qpidd rpm

 * directories %{_libdir}/qpid and %{_libdir}/qpid/client --> should be 
   owned by the qpidc rpm

 * directory %{_sysconfdir}/qpid  -->  should be owned by the qpidc rpm

 * directory %{_includedir}/qpid  -->  should be owned by the qpidc-devel rpm

/jpo

qpidc-0.4.734452-2.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/qpidc-0.4.734452-2.fc10

qpidc-0.4.734452-2.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/qpidc-0.4.734452-2.fc9

Nuno,

There is a problem with your solution: the qpidc and qpidd rpms are now shipping with the extensions libraries.

qpidc rpm listing
-----------------
--- qpidc-0.4.734452-1.txt      2009-01-21 19:04:52.000000000 +0000
+++ qpidc-0.4.734452-2.txt      2009-01-21 19:04:48.000000000 +0000
@@ -1,8 +1,12 @@
+/etc/qpid
 /etc/qpid/qpidc.conf
 /usr/lib64/libqpidclient.so.0
 /usr/lib64/libqpidclient.so.0.1.0
 /usr/lib64/libqpidcommon.so.0
 /usr/lib64/libqpidcommon.so.0.1.0
+/usr/lib64/qpid/client
+/usr/lib64/qpid/client/rdmaconnector.so
+/usr/lib64/qpid/client/sslconnector.so
 /usr/share/doc/qpidc-0.4.734452
 /usr/share/doc/qpidc-0.4.734452/DESIGN
 /usr/share/doc/qpidc-0.4.734452/INSTALL


Note: same thing happened with the qpidd rpms.

When you add a line like

  %_libdir/qpid/client

in the specfile, it pulls in everything installed under that location (files and subdirectories). As you only want to include the directory you need to prefix them with "%dir ".

Examples:

--- qpidc.spec.2        2009-01-21 15:49:47.000000000 +0000
+++ qpidc.spec  2009-01-21 18:57:04.000000000 +0000
@@ -238,8 +238,8 @@
 %_libdir/libqpidcommon.so.0.1.0
 %_libdir/libqpidclient.so.0
 %_libdir/libqpidclient.so.0.1.0
-%_libdir/qpid/client
-%_sysconfdir/qpid
+%dir %_libdir/qpid/client
+%dir %_sysconfdir/qpid
 %config(noreplace) %_sysconfdir/qpid/qpidc.conf
 
 %files devel
@@ -268,7 +268,7 @@
 %config(noreplace) %_sysconfdir/qpidd.conf
 %config(noreplace) %_sysconfdir/sasl2/qpidd.conf
 %{_initrddir}/qpidd
-%_libdir/qpid/daemon
+%dir %_libdir/qpid/daemon
 %attr(755, qpidd, qpidd) %_localstatedir/lib/qpidd
 %attr(755, qpidd, qpidd) %_libdir/qpidd
 %attr(755, qpidd, qpidd) /var/run/qpidd

Yes, you're absolutely right, it was an oversight from my side. 

The most recent builds (qpidc-0.4.734452-4.fc10/.fc9 and qpidc-0.4.734452-3 on rawhide) fix that issue, they should be in updates soon.

Thanks,
Nuno

*** Bug 474613 has been marked as a duplicate of this bug. ***

Nuno,

We are still missing one directory ownership in qpidc-0.4.734452-4:

Problem:

  $ rpm -qf /usr/lib/qpid
  file /usr/lib/qpid is not owned by any package

Solution:

  The qpidc rpm should own "%_libdir/qpid".  Missing line in the specfile:

            %dir %_libdir/qpid


Other problems (minor) detected:

 * Ownership of /usr/include/qpid/broker

   # rpm -qf /usr/include/qpid/broker
   qpidc-devel-0.4.734452-4.el5
   qpidd-devel-0.4.734452-4.el5

   It should belong only to qpidd-devel.

 * The qpidd rpm owns the directory /usr/lib/qpidd but it appears to be
   unused.  Specfile line:
     %attr(755, qpidd, qpidd) %_libdir/qpidd


Possible patch (only for the first 2 problems):
----------
$ diff -u qpidc.spec.4 qpidc.spec
--- qpidc.spec.4        2009-01-22 00:58:20.000000000 +0000
+++ qpidc.spec  2009-01-23 03:16:58.000000000 +0000
@@ -238,12 +238,14 @@
 %_libdir/libqpidcommon.so.0.1.0
 %_libdir/libqpidclient.so.0
 %_libdir/libqpidclient.so.0.1.0
+%dir %_libdir/qpid
 %dir %_libdir/qpid/client
 %dir %_sysconfdir/qpid
 %config(noreplace) %_sysconfdir/qpid/qpidc.conf
 
 %files devel
 %defattr(-,root,root,-)
+%dir %_includedir/qpid
 %_includedir/qpid/*.h
 %_includedir/qpid/amqp_0_10
 %_includedir/qpid/client
@@ -253,7 +255,6 @@
 %_includedir/qpid/log
 %_includedir/qpid/management
 %_includedir/qpid/agent
-%_includedir/qpid
 %_includedir/qmf
 %_libdir/libqpidcommon.so
 %_libdir/libqpidclient.so
----------

qpidc-0.4.734452-4.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

qpidc-0.4.734452-4.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

Re-opening...

As explained in the 5th comment the qpidc-0.4.734452-4 update didn't fixed all the problems.

(In reply to comment #12)
> Re-opening...
> 
> As explained in the 5th comment the qpidc-0.4.734452-4 update didn't fixed all
> the problems.

Oops! It should have been the 9th comment...

Ticket still requires attention.

Source:
https://www.redhat.com/archives/fedora-extras-commits/2009-January/msg09770.html

Note:
The ownership of  %_libdir/qpid  by the qpidc rpm is still missing.

Everything appears to be fine now:

  * The %_libdir/qpid is owned by the qpidc rpm
  * No dual packaging of the broker include files

Tests:
  $ rpm -qf /usr/include/qpid/broker/Timer.h
  qpidd-devel-0.4.738618-3

  $ rpm -qf /usr/include/qpid/broker/
  qpidd-devel-0.4.738618-3

  $ rpm -qf /usr/include/qpid/
  qpidc-devel-0.4.738618-3

  $ rpm -qf /usr/lib/qpid/
  qpidc-0.4.738618-3.el5

Nuno,

You also need to rebuild rhm against the new qpidc as its requirements are hardcoded to the qpidc svn revision number:

  rhm specfile
  ----------
  #
  # Spec file for Red Hat Messaging package rhm.
  #

  %define svnrev 3045
  # built against qpidc svn rev: 
  %define svnrev_qpid 734452
  ...
  Requires: qpidd = 0.4.%{svnrev_qpid}
  ...
  ----------

Yes, I'm aware of that -- I'm waiting for the rpms to be moved into the buildroots so that I can build rhm. I'll then push the whole set as an update to F10 (and F9 too).

Nuno

Closing.