mock-chroot> rpm -qf /usr/share/systemtap file /usr/share/systemtap is not owned by any package mock-chroot> rpm -qf /usr/share/systemtap/tapset/ file /usr/share/systemtap/tapset is not owned by any package mock-chroot> rpm -qf /usr/share/systemtap/tapset/x86_64/ file /usr/share/systemtap/tapset/x86_64 is not owned by any package mock-chroot> rpm -qf /usr/share/systemtap/tapset/x86_64/* java-1.6.0-openjdk-devel-1.6.0.0-53.1.9.6.fc15.x86_64 java-1.6.0-openjdk-devel-1.6.0.0-53.1.9.6.fc15.x86_64 java-1.6.0-openjdk-devel-1.6.0.0-53.1.9.6.fc15.x86_64 java-1.6.0-openjdk-devel should either own the /usr/share/systemtap, /usr/share/systemtap/tapset, and /usr/share/systemtap/tapset/$arch dirs or depend on a package that owns them.
We discussed this a bit on systemtap irc. The consensus seemed to be that if a package has a tapset then it should be put under the appropriate /usr/share/systemtap/tapset/ directory, but the package doesn't need to depend on systemtap because it can function without it just fine. So the package needs to own (%dir) those directories. This seems to be what https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership says under "The directory is owned by a package which is not required for your package to function".
Agreed.
openjdk dvel already owns /usr/share/systemtap/tapset/%{_build_cpu}/*.stp Isn't that enough?
Created attachment 504620 [details] proposed aptch to openjdk specfile
For what purpose we need to own systemtap directory at all?
(In reply to comment #4) > Created attachment 504620 [details] > proposed aptch to openjdk specfile If I read the patch correctly, it's not enough - it'd still leave /usr/share/systemtap and %tapsetdir (e.g. /usr/share/systemtap/tapset/x86_64) unowned. (In reply to comment #5) > For what purpose we need to own systemtap directory at all? http://fedoraproject.org/wiki/Packaging/Guidelines#File_and_Directory_Ownership
(In reply to comment #6) > (In reply to comment #5) > > For what purpose we need to own systemtap directory at all? > > http://fedoraproject.org/wiki/Packaging/Guidelines#File_and_Directory_Ownership AHA. Thanks. Indeed. systemtap would normally own /usr/share/systemtap and subdirectories. But systemtap isn't a hard dependency for this package. Those tapsets are just placed there in case a user wants to use them so systemtap, if installed, can easily find them. So the -devel package should also own the directories.
Created attachment 504835 [details] patch based on comment 6 and 7
(In reply to comment #8) > Created attachment 504835 [details] > patch based on comment 6 and 7 That would leave /usr/share/systemtap and /usr/share/systemtap/tapset unowned. Something like this should fix it properly (untested): diff --git a/java-1.6.0-openjdk.spec b/java-1.6.0-openjdk.spec index 3b2612b..7985376 100644 --- a/java-1.6.0-openjdk.spec +++ b/java-1.6.0-openjdk.spec @@ -133,3 +133,4 @@ #%define tapsetdir /usr/share/systemtap/tapset/%{sdkdir} -%define tapsetdir /usr/share/systemtap/tapset/%{_build_cpu} +%define tapsetroot /usr/share/systemtap +%define tapsetdir %{tapsetroot}/tapset/%{_build_cpu} %endif @@ -865,3 +866,3 @@ exit 0 %ifarch %{jit_arches} -%{tapsetdir}/*.stp +%{tapsetroot} %endif
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
java-1.6.0-openjdk is not included in Fedora 19. On Fedora 19, java-1.7.0-openjdk owns /usr/share/systemtap and /usr/share/systemtap/tapsets. On Fedora 20 java-1.{7,8}.0-openjdk own /usr/share/systemtap and /usr/share/systemtap/tapsets. I think we can close this bug as fixed now.
(In reply to Omair Majid from comment #11) > I think we can close this bug as fixed now. Or rather as CANTFIX because it actually never got fixed in the package it was reported against, and that package no longer exists in any active Fedora versions.