This morning, with an uptodate F12 with kde and without gnome, I tried yum --enablerepo updates-testing update kdelibs As expected, it drew a lot of packages to install/update as dependencies. I noticed in the package lists it proposed to install large parts of the gnome desktop. Looking at yum output, it looked like the package "blueman" required the gnome desktop, but I couldn't see what required blueman. I tried yum --enablerepo updates-testing --exclude blueman update kdelibs expecting to see an error message, but it worked and I could update kde without installing gnome. So, either blueman is somehow required and the second run should not have worked, either it is not required and it should not have been pulled in the first run. I expect of yum to pull the minimal amount of packages needed to install/update the packages I demand, and not one more. Here, it looks like yum decided to add something extra to my request. Why ?
It sounds like a case where multiple packages provides something that kdelibs needs and the "Wrong" one gets selected. if kdelibs needs 'foobar' and blueman provide 'foobar' and the johndoe provides 'foobar' then yum has no way to know that johndoe is "best" choice and not blueman. When you exclude 'blueman' then there is only one choice 'johndoe' and every thning goes as you expect. This can only be fixed by adjusting the requirement of kdelibs or the deps there pull in blueman. could you attach the output from yum -v --enablerepo updates-testing update kdelibs and yum --enablerepo updates-testing --exclude blueman update kdelibs So it will be easier to find the package causing the trouble.
and the output from yum --enablerepo=updates-testing deplist kdelibs Would be nice too :)
Thanks for your answer, I understand why it happened that way. I tried what you suggest but it didn't help as blueman was not pulled by kdelibs but by a dependency of kdelibs. I tried to investigate, and I __think__ that the actual path was kdelibs requires kdebase-workspace kdebase-workspace requires bluez (which is already stupid: kde works very well on a computer without bluetooth ! This dependency should not be here.) bluez requires "dbus-bluez-pin-helper" "dbus-bluez-pin-helper" is provided by kdebluetooth, kbluetooth (why are there two of them ?), gnome-bluetooth and blueman and that's probably how blueman was drawn. I still think it is not satisfactory. Maybe there should be an interactive mode of yum, where dependencies provided by only one package are automatically pulled, but if several packages would fit the bill, yum stops with a message "the dependency xyz of package foobar could be provided by a, b or c. the dependency zyx of package barfoo could be provided by d or e Please rerun yum and add explicitely which of those packages you choose to install on the command line." just to give a little bit more control.
The right solution is that kdebase-workspace should require kdebluetooth or kbluetooth, then this would not happen.
reassigning to kdebase-workspace for comments :)
We implemented comment #4 in kdebase-workspace-4.4.0-5.1 %changelog * Tue Feb 16 2010 Rex Dieter <rdieter> - 4.4.0-5.1 - Requires: kbluetooth (<f13) For F-13+, we added kbluetooth as a default item in @kde-desktop group.
If I may comment, I find it horribly broken that installing bluetooth support is required when using KDE. Not all computers have bluetooth, not everyone who has bluetooth support wants to use it, and requiring of everyone to have kbluetooth or similar is very unclean, frustrating, iritating, not as-it-should. Why can't I have plasma+kwin+konqueror+konsole without bluetooth ? That's an unwanted dependency !
As it is, kde's bluetooth support requires the presence of bluez to function properly (and bluez requires a pin helper). So, we can either have bluetooth/kde stuff that "just works" or ... not. Now, we can certainly consider splitting out bluetooth support in future packaging to make that optional, but that's going to take a lot of effort, time, and patience to get right. Honestly, it's probably not on our radar to implement ourselves any time soon. If you or anyone else is passionate about and wants to help work on this, the help would be well-received.
The bluez dependency was added in 4.4.0 in the first place, so I'm removing this from the "fixed in 4.4" list. The thing with that dependency is, technically it's correct as kdebase-workspace contains solid-bluetooth which requires bluez. Then bluez wants some UI because you need to be able to enter required PINs in the UI, so it drags in a virtual Provides for a UI which is fulfilled by one of several options, one of which is kbluetooth. So we added an explicit Requires: kbluetooth in the latest package to enforce the correct choice. Still, I'm starting to think we should just remove those dependencies from kdebase-workspace and instead just add Requires: bluez to kbluetooth. Also because the dependency between kdebase-workspace and kbluetooth is circular, which is bound to cause trouble sooner or later.
> Now, we can certainly consider splitting out bluetooth support in future > packaging to make that optional, but that's going to take a lot of effort, > time, and patience to get right. Honestly, it's probably not on our radar to > implement ourselves any time soon. AFAICT, all it takes is removing the 2 explicit Requires we added to kdebase-workspace and instead add Requires: bluez to kbluetooth (the other option we discussed on IRC when the "nothing drags in bluez" problem first came up). It's less technically correct, but in practice I think kbluetooth is the only thing actually using Solid-Bluetooth anyway.
Fair enough, that may be a good enough solution indeed.
> I think kbluetooth is the only thing actually using Solid-Bluetooth anyway Then maybe the solution would be to put solid-bluetooth (whatever it is) in the kbluetooth package ? This way * kdebase-workspace does no longer require bluetooth and you can install kde without pulling the full bluetooth stack * you enforce the fact that kbluetooth and solid-bluetooth be both installed together without playing with requirements. kbluetooth becomes a self contained kde interface to bluetooth. You'll tell me that they are not developped by the same person, but then it looks so more logical to put all the bits about bluetooth in kde in one package called kbluetooth instead of spreading those bits in several packages !
This bug has been triaged Steven M. Parrish KDE & Packagekit Triager Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Adjusting summary to match reality. We can't dictate how kde releases things really, but can certainly make the suggestion... regardless, it does indeed make sense that kbluetooth and solid-bluetooth live closer together. In the meantime, I'll work on implementing the plan as outlined in comment #10
kdebase-workspace-4.4.0-7.fc13,kbluetooth-0.4.1-2.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/kdebase-workspace-4.4.0-7.fc13,kbluetooth-0.4.1-2.fc13
kdebase-workspace-4.4.0-8.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/kdebase-workspace-4.4.0-8.fc13
kdebase-workspace-4.4.0-8.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.