Bug 744907

(In reply to comment #0)
> Description of problem:
> systemtap and it's subpackages have several unowned directories:
> %{_libdir}/systemtap
> %{_libexecdir}/systemtap

These two we should fix.

> %{_datadir}/systemtap
> %{_datadir}/systemtap/tapset

(fixed, assuming you meant %{_datadir})

These two are owned by the base systemtap package on my machine, so I'm not sure why your search would flag it.

> %{_datadir}/systemtap/tapsets

This one is due to bug #712726.

I don(In reply to comment #1)
> These two are owned by the base systemtap package on my machine, so I'm not
> sure why your search would flag it.

Indeed, according to the spec they are owned. I no longer have systemtap installed on my machine and rpm reported the dirs unowned, so there are two options:
- they were unowned in a previous version of the package
- it's possible to install something that puts files there without installing systemtap.

(In reply to comment #2)
> - it's possible to install something that puts files there without installing
> systemtap.

Indeed, repoquery -f '/usr/share/systemtap/tapset/*' shows several other packages that install .stp files for systemtap use.  These are generally thought of as soft dependencies, where they don't want to force a systemtap requirement, but they want that available if you do have systemtap installed.

I suppose these other packages should either split those into subpackages that depend on systemtap, or just share that directory ownership with us.

(In reply to comment #3)
> I suppose these other packages should either split those into subpackages that
> depend on systemtap, or just share that directory ownership with us.

And FWIW, openjdk already demonstrates the latter option:

$ repoquery -f '/usr/share/systemtap' | sort -u
java-1.7.0-openjdk-devel-1:1.7.0.0-0.1.20110803.1.fc16.i686
java-1.7.0-openjdk-devel-1:1.7.0.0-0.1.20110803.1.fc16.x86_64
systemtap-0:1.6-1.fc16.x86_64

$ repoquery -f '/usr/share/systemtap/tapset' | sort -u
java-1.7.0-openjdk-devel-1:1.7.0.0-0.1.20110803.1.fc16.i686
java-1.7.0-openjdk-devel-1:1.7.0.0-0.1.20110803.1.fc16.x86_64
systemtap-0:1.6-1.fc16.x86_64

(In reply to comment #3)
> I suppose these other packages should either split those into subpackages that
> depend on systemtap, or just share that directory ownership with us.

I think sharing is fine.

(In reply to comment #1)
> > %{_libdir}/systemtap
> > %{_libexecdir}/systemtap
> 
> These two we should fix.

These are fixed in upstream commit 75ab1a70, and I also pushed them to Fedora's systemtap dist-git.  I don't feel this is worth pushing out a build now, but they'll get fixed next time we do.

(In reply to comment #5)
> (In reply to comment #3)
> > I suppose these other packages should either split those into subpackages that
> > depend on systemtap, or just share that directory ownership with us.
> 
> I think sharing is fine.

So should we dupe this bug for each offender?  For F16, that list is:

$ diff -u <(repoquery -sf '/usr/share/systemtap/tapset' | sort -u) \
          <(repoquery -sf '/usr/share/systemtap/tapset/*' | sort -u)
--- /dev/fd/63	2011-10-18 15:19:03.945306530 -0700
+++ /dev/fd/62	2011-10-18 15:19:03.946306521 -0700
@@ -1,2 +1,9 @@
+glib2-2.30.0-2.fc16.src.rpm
 java-1.7.0-openjdk-1.7.0.0-0.1.20110803.1.fc16.src.rpm
+libvirt-0.9.6-2.fc16.src.rpm
+perl-5.14.1-187.fc16.src.rpm
+perl-5.14.1-188.fc16.src.rpm
+python-2.7.2-4.fc16.src.rpm
+python3-3.2.1-1.fc16.src.rpm
+qemu-0.15.0-5.fc16.src.rpm
 systemtap-1.6-1.fc16.src.rpm

upstream commit 75ab1a70 for the systemtap.spec changes from above.