This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 761270 - Obsoletion of polkit-desktop-policy not handled properly, yum wants to install both x86_64 and i686 polkits
Obsoletion of polkit-desktop-policy not handled properly, yum wants to instal...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: polkit (Show other bugs)
19
Unspecified Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: Miloslav Trmač
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-12-07 17:37 EST by Adam Williamson
Modified: 2013-04-12 22:17 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-04-12 22:16:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Adam Williamson 2011-12-07 17:37:07 EST
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.
Comment 1 David Zeuthen 2011-12-08 16:55:46 EST
IIRC last time this happened it was a problem with yum... I'm really not sure what I can do to fix this....
Comment 2 Kevin Kofler 2011-12-08 17:55:19 EST
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.
Comment 3 David Zeuthen 2011-12-08 18:21:20 EST
(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.
Comment 4 Kevin Kofler 2011-12-08 18:31:54 EST
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.
Comment 5 Kevin Kofler 2011-12-08 18:34:37 EST
(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!)
Comment 7 David Zeuthen 2011-12-09 10:31:09 EST
(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.
Comment 8 Clyde E. Kunkel 2011-12-13 10:13:13 EST
Hey...nuff.  What is the fix and when?  Please!
Comment 9 Adam Williamson 2011-12-13 12:50:31 EST
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
Comment 10 Clyde E. Kunkel 2011-12-13 16:28:44 EST
Well, thats easy enough.  Wish that had been the response earlier instead of all this folderall.
Comment 11 Thomas Spura 2011-12-16 12:01:38 EST
(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)
Comment 12 Fedora Admin XMLRPC Client 2013-02-01 18:59:24 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 13 Fedora End Of Life 2013-04-03 12:20:32 EDT
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
Comment 14 Miloslav Trmač 2013-04-12 22:16:28 EDT
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).

Note You need to log in before you can comment on or make changes to this bug.