One or more directories are not included within this package and/or its sub-packages: => xfce4-sensors-plugin-0.10.99.6-1.fc11.i386 (rawhide-development-i386) /usr/lib/xfce4/modules provided by: xfdesktop-4.4.2-6.fc10.i386 provided by: xfce4-mixer-4.4.3-2.fc11.i386 [...] Further information: https://fedoraproject.org/wiki/Packaging/ReviewGuidelines MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. https://fedoraproject.org/wiki/Packaging/Guidelines#FileAndDirectoryOwnership https://fedoraproject.org/wiki/Packaging/UnownedDirectories
=> xfce4-sensors-plugin-devel-0.10.99.6-1.fc11.i386 (rawhide-development-i386) /usr/lib/xfce4/modules provided by: xfdesktop-4.4.2-6.fc10.i386 provided by: xfce4-mixer-4.4.3-2.fc11.i386 It may be convenient to include this directory in multiple packages.
Kevin, any thoughts?
Well, this was one of the packages we were talking about renaming due to it working as a standalone as well as a plugin? If we do that, we can make the plugin subpackage require xfdesktop and the main package doesn't need to. In the mean time we can probibly just have it own the directory as well. I wonder if xfce4-mixer should be fixed to have a xfdesktop dependency as well and remove that dir from it's ownership. Thoughts?
I don't like the idea of making the mixer depend on the desktop, that's what comps is for. IMO we should %{_libdir}/xfce4/modules to xfce-mcs-manager as we previously did with %{_libdir}/xfce4.
ok, I guess that would be fine with me too. Did you want to just go ahead and make those changes in F9/F10? This problem goes away in rawhide as mcs goes away there.
Ok, will do. reassigning to xfce-mcs-manager, reamains assigned to me.
Sorry, BZ has automatically assigned the bug to you, resetting.
Fixed in xfce-mcs-manager-4.4.3-1.fc10.1, but not fixed in rawhide, because xfce-mcs-manager has been superseded by xfce4-settings there.
xfce-mcs-manager-4.4.3-1.fc10.1 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update xfce-mcs-manager'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-1342
Original problem unfixed: => xfce4-sensors-plugin-0.10.99.6-3.fc11.src.rpm => xfce4-sensors-plugin-0.10.99.6-3.fc11.i586 (rawhide) /usr/lib/xfce4/modules provided by: xfdesktop-4.6.0-3.fc11.i586 => xfce4-sensors-plugin-0.10.99.6-3.fc11.src.rpm => xfce4-sensors-plugin-devel-0.10.99.6-3.fc11.i586 (rawhide) /usr/lib/xfce4/modules provided by: xfdesktop-4.6.0-3.fc11.i586 [...] The script to find unowned directories is not complete yet, but still quite usable: http://mschwendt.fedorapeople.org/dircheck-remote.py $ ./dircheck-remote.py -r rawhide -n ^xfce-sensors
(In reply to comment #10) > Original problem unfixed: No, the original problem is fixed, because the bug was filed against Xfce 4.4 but now you are complainaing about 4.6. You/your skript is right, but I think this is no real world issue, because people who are using the sensors plugin are using it in Xfce, so they have xfdesktop installed. If you still think this needs to be fixed, what is you suggestion?
April fool's joke? Original report: xfce4-sensors-plugin-0.10.99.6-1.fc11.src.rpm Comment 10: xfce4-sensors-plugin-0.10.99.6-3.fc11.src.rpm Also note that the "xfce4-sensors-plugin-devel" package is affected, too, and doesn't pull in anything that owns the directory. If you don't know how to fix it (e.g. by fixing the dependency-chain), close the ticket.
(In reply to comment #12) > April fool's joke? > > Original report: xfce4-sensors-plugin-0.10.99.6-1.fc11.src.rpm > Comment 10: xfce4-sensors-plugin-0.10.99.6-3.fc11.src.rpm Please look at the component this bug is assigned to. The problem is not the sensors plugin but xfdesktop or xfce-mcs-manager and the latter is retired in rawhide. > Also note that the "xfce4-sensors-plugin-devel" package is affected, too, and > doesn't pull in anything that owns the directory. Yes, but why would someone want to develop something based on an Xfce panel plugin if he is not running Xfce? > If you don't know how to fix it (e.g. by fixing the dependency-chain), close > the ticket. As you are the one who filed this bug I'd like to hear a constructive suggestion from you. How can I be sure you wont open another bug next time you run your script? Basically, we have the options 1. Make sensors plugin require xfdesktop. IMO this is not fixing the dependency chain but making it worse. 2. Let xfconf own the dir. Looks strange because xfconf does not put anything in there, but will do. 3. Duplicate ownership. This is according to the packaging guidelines because this is exactly the scenario described as an exception from the rule of thumb. Please tell me which solution you prefer.
> Please look at the component this bug is assigned to. You did that. See ticket log. ;) > How can I be sure you wont open another bug next time you > run your script? It's very unlikely that I will let a script file such tickets again, because unowned directories have become less of a problem since RPM 4.4.2.3: https://fedoraproject.org/wiki/Packaging/UnownedDirectories I've been revisiting and closing open tickets, though, also in search for cases where finding unowned directories leads to finding other problems. > a constructive suggestion Duplicated ownership is fine in this case and IMHO.
(In reply to comment #14) > You did that. See ticket log. ;) I know. I had to change it because your script cannot replace human intelligence. ;) > Duplicated ownership is fine in this case and IMHO. Done in 0.10.99.6-4. Resetting to ON_QA and let xfce-mcs-manager close the bug once it gets stable. Thanks for your report and all the work you've put into this.
xfce-mcs-manager-4.4.3-1.fc10.1 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.