In Rawhide it seems like a new 'polkit' package has been introduced which obsoletes 'polkit-desktop-policy'. polkit is arch, while p-d-p was noarch. The obsoletion seems to get something wrong - I don't know what - because on an x86_64 system 'yum update' wanted to install *both* polkit.x86_64 and polkit.i686 to replace polkit-desktop-policy. I'm not sure how you'd go about making this not happen, but it's obviously not desired.
IIRC last time this happened it was a problem with yum... I'm really not sure what I can do to fix this....
Why are we dropping this policy in the first place? As you yourself admitted in: https://bugs.freedesktop.org/show_bug.cgi?id=41008#c1 you only upstreamed parts of it, and so removing the other part results in a regression. I also fail to see ANY attempt at communicating this change to the maintainers of the affected mechanisms, at least I haven't heard of anything for org.kde.kcontrol.kcmclock.save.
(In reply to comment #2) > Why are we dropping this policy in the first place? Because it's not a good idea to maintain it centrally. In fact it's a bad thing. > As you yourself admitted > in: > https://bugs.freedesktop.org/show_bug.cgi?id=41008#c1 > you only upstreamed parts of it, and so removing the other part results in a > regression. Oh, boy, don't no need to be so dramatic about it. If you read what I said, it was that "mechanisms should be more lenient". Which is completely the right answer. Think about it: it's not my place (as the polkit maintainer) to override policy that only the mechanism author can truly vet. If I did so, it means that I take responsible for such a change and I don't want to do that. Second, don't use the word 'regression' like that. It's not like anything breaks - all it means it that users will have to authenticate. Calling that a 'regression' is just ridiculous. If this extra authentication step is a problem for _you_, then _you_ take it up with the mechanism maintainer. Or _your_ package can ship its own .pkla files. Just don't make it _my_ problem. > I also fail to see ANY attempt at communicating this change to the maintainers > of the affected mechanisms, at least I haven't heard of anything for > org.kde.kcontrol.kcmclock.save. Actually, I never added org.kde.kcontrol.kcmclock.save - you did: http://pkgs.fedoraproject.org/gitweb/?p=polkit.git;a=commitdiff;h=fb2802ef271399df4abd8fab5b3d684d2e8c6124 And you did this without asking me probably because you felt entitled. Please don't hijack bugs in the future. If you still feel a need to vent, at least open a new bug for it instead of abusing this one. Seriously.
I added it because the GNOME equivalent was listed there and there is no sense in allowing setting the clock with GNOME tools with no password prompt and not doing the exact same thing with KDE tools. Sure, we can and probably will move the setting to kde-settings. But it would have been nice to at least be TOLD about the change, rather than only learning about it by accident, because the Obsoletes are breaking things. And I think this is on topic here because IMHO resurrecting polkit-desktop-policy (minus the upstreamed part) is the best way to make this bug go away.
(and the reason why I'm "venting" is because this is not the first time I only learn by accident about a change you make in low-level components and which affects the desktops. Please COMMUNICATE such changes!)
https://fedoraproject.org/wiki/Package_maintainer_responsibilities#Notify_others_of_changes_that_may_affect_their_packages
(In reply to comment #4) > I added it because the GNOME equivalent was listed there and there is no sense > in allowing setting the clock with GNOME tools with no password prompt and not > doing the exact same thing with KDE tools. Next time you want to modify my packages, at least ask me about it. > Sure, we can and probably will move the setting to kde-settings. But it would > have been nice to at least be TOLD about the change, rather than only learning > about it by accident, because the Obsoletes are breaking things. > > And I think this is on topic here because IMHO resurrecting > polkit-desktop-policy (minus the upstreamed part) is the best way to make this > bug go away. No, sorry, centralized policy is not coming back. Either way, please don't continue posting on this bug about it. I've already told you it's off-topic here.
Hey...nuff. What is the fix and when? Please!
clyde: it's easy enough to work around by just 'yum install polkit.x86_64'. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Well, thats easy enough. Wish that had been the response earlier instead of all this folderall.
(In reply to comment #0) > I'm not sure how you'd go about making this not happen, but it's obviously not > desired. It's a yum problem... see bug 667984 comment 3 (python-argparse was noarch, where python is not)
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
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
Per packaging guidelines, obsoletes/provides are supported only for 2 Fedora versions, so this problem will "solve itself" by F19 no longer being concerned about upgrades from F16 (which is the last release that had polkit-desktop-policy).