Description of problem:
gnome-settings-daemon should not require PackageKit. As the dependency only is caused by the updates plugin, it should be easy to package it separately.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot F15 Beta Desktop live
2. # yum remove Packagekit
24 packages will be removed, most of them like gdm, empathy, gnome-panel or orca have nothing to do with package management and don't reply on any of it's functionality.
Only a few packages should be removed, most important not gnome-settings-deamon.
The updates it to configure packageKit, thus it should be part of gnome-packagekit rather than gnome-settings-daemon. If it needs to be part of the latter, it should be a sub-package. We could use a conditional to automatically install it if necessary.
*** Bug 699263 has been marked as a duplicate of this bug. ***
(In reply to comment #0)
> Additional info:
> The updates it to configure packageKit,
Should read: "The updates plugin is to configure PackageKit."
If the updates plugin remains part of gnome-settings-deamon rather than gnome-packagekit we need to have g-s-d depend on gnome-packagekit because there is no use in having the plugin but not gpk-update-viewer installed. However I strongly recommend to not add this dependency but to make a sub-package that then can have a dep on gnome-packagekit.
Even better: Move the plugin to gnome-packasgekit, but this is something that needs to happen upstream in the GNOME 3.2 development cycle.
A. "However I strongly recommend to not add this dependency but to make a sub-package that then can have a dep on gnome-packagekit."
B. "Even better: Move the plugin to gnome-packasgekit, but this is something that needs to happen upstream in the GNOME 3.2 development cycle."
Sounds good as this would satisfy the requirements, including the PackageKit integration plan within GNOME 3, and the expectations of every user/developer.
Can we move to A. and push for B. (now, short term)?
B is a nonstarter. gnome-settings-daemons plugin system is not a dumping ground for 3rd party plugins. The updates plugin is in g-s-d because it is an integral part of the gnome experience.
I don't accept 'I want to yum remove PackageKit, but I don't want anything important to disappear' as a valid request either.
The one reason why I am willing to consider a subpackage for the updates plugin is that there are other spins getting a big chunk of gnome dependencies indirectly via gdm -> gnome-settings-daemon ...
> The one reason why I am willing to consider a subpackage for the updates
> plugin is that there are other spins getting a big chunk of gnome
> dependencies indirectly via gdm -> gnome-settings-daemon ...
So is this an agreement? Are we moving towards the resolution of this issue?
Thanks a lot,
(In reply to comment #4)
> I don't accept 'I want to yum remove PackageKit, but I don't want anything
> important to disappear' as a valid request either.
I was assured repeatedly by Richard, that PackageKit is not meant to cover every possible use case and particularly that it is not designed for users of Rawhide and similar constantly partially broken repos.
Did anything change on this? So, PackageKit is now expected to work even with Rawhide?
Btw; whoever provides a patch to move the plugin to a subpackage also has the job of figuring out a good place to add the artificial dependency that ensures that we don't loose the functionality in gnome on upgrades.
Every time we accept one of these package splits, upgrading gnome users tend to loose functionality (most recently, I got questions about where the 'add to archive' functionality in nautilus went - answer: into the fileroller-nautilus subpackage), and we get to maintain a growing set of artificial deps that tend to draw flak from the same group of people who asked for the split in the first place...
if the updates plugin is split into a
gnome-settings-plugin-packagekit and that gnome-packagekit requires gnome-settings-plugin-packagekit then it will be installed if you updates a system with gnome-packagekit installed. but will not be installed if you updates a system without gnome-packagekit.
No magic is needed and the updates plugin can do anything without gnome-packagekit anyway.
(In reply to comment #7)
> Btw; whoever provides a patch to move the plugin to a subpackage also has the
> job of figuring out a good place to add the artificial dependency that ensures
> that we don't loose the functionality in gnome on upgrades.
> Every time we accept one of these package splits, upgrading gnome users tend to
> loose functionality (most recently, I got questions about where the 'add to
> archive' functionality in nautilus went - answer: into the fileroller-nautilus
> subpackage), and we get to maintain a growing set of artificial deps that tend
> to draw flak from the same group of people who asked for the split in the first
I see your point, but it's also problem for rest of us. I suppose if someone is using GNOME, then he can simply install whole GNOME group. If someone need minimal dependency chain for his spin, then it's problem...
'minimal depencdency chain' and 'using interrelated bits and pieces of another desktop' are not really compatible. There were more compatible with GNOME2, but that is changing with GNOME3.
Created attachment 548820 [details]
Patch to split the updates plugin in sub-package
This shows how little modification is needed to make it possible, to remove PackageKit without removing gdm etc.
gnome-packagekit can require the gnome-settings-daemon-updates package, to make sure it gets installed by default if gnome-packagekit is installed.
I am a strong supporter of giving people choices to choose what software they want to use and if they don't what to use PackageKit they should have the choice to uninstall it.
There is no technical reason not split out gnome-settings-deamon updates i a subpackage that will make it possible for user to remove PackageKit if it get in there way. (See Comment #11)
I know that is PackageKit is removed totem can't not automatic download plugins etc. Like firefox don't can show flash, if you don't install a flash plugin, but that don't mean I can't run firefox if I don't install flash.
Here's another datapoint: I manage a lab with cca. 100 fedora machines, and I really really don't want users updating packages willy-nilly on them. It's really reassuring to see all machines updating the *same* number of packages when I run a 'yum update' from a script across the entire lab.
In the past, I could "lock them down" by simply removing PackageKit. Now, while the outcome of this bug is being decided, I'm stuck editing /usr/share/polkit-1/actions/org.freedesktop.packagekit.policy and replacing '<allow_active>yes' with '<allow_active>auth_admin_keep', to stop random users from randomly updating random machines, throwing off my count and causing me lots of anxiety.
That worked OK until mid-April, when PackageKit-0.6.22-1.fc16 rolled around and overwrote my /usr/share/polkit-1/actions/org.freedesktop.packagekit.policy edits, re-enabling my random users' ability to apply random updates to my lab machines.
Can we *at least* agree to mark org.freedesktop.packagekit.policy as config(noreplace), absent a better way to make polkit changes that would survive an update ?
Or better yet, make PackageKit easy to remove without giving up on half the Gnome desktop, and allow everyone to get on with their lives... :)
you could just remove gnome-packagekit frontend too
(In reply to comment #14)
> you could just remove gnome-packagekit frontend too
I could, but there's always 'pkcon update'. And I'm talking about smart, inquisitive, pain-in-my-neck kids in that lab, so that'd buy me an extra 20 minutes at best :)
(In reply to comment #13)
> That worked OK until mid-April, when PackageKit-0.6.22-1.fc16 rolled around and
> overwrote my /usr/share/polkit-1/actions/org.freedesktop.packagekit.policy
> edits, re-enabling my random users' ability to apply random updates to my lab
> Can we *at least* agree to mark org.freedesktop.packagekit.policy as
> config(noreplace), absent a better way to make polkit changes that would
> survive an update ?
Files in /usr are supposed to be overwritten by updates. If not, they belong to /etc. This being said you should make your changes in /etc/polkit-1/localauthority/50-local.d, e.g. in a file called 50-custom-desktop-policy.pkla. These rules will then overwrite what is in /usr/share/polkit-1/actions/org.freedesktop.packagekit.policy or /etc/polkit-1/localauthority/(10-vendor.d,20-org.d,30-site.d).
(In reply to comment #16)
> This being said you should make your changes in
> /etc/polkit-1/localauthority/50-local.d, e.g. in a file called
> 50-custom-desktop-policy.pkla. These rules will then overwrite what is in
> /usr/share/polkit-1/actions/org.freedesktop.packagekit.policy or
Thanks for that, should come in handy for other polkit-related tweaks as well (I'm also locking down the ability of console users to e.g. hibernate or reboot, or mess with NetworkManager settings, etc.).
That being said, I still maintain that in a large-scale managed deployment it'd be MUCH cleaner to simply remove PackageKit than try to remove the privileges it grants that are intended for single-user systems, by enumeration. Kinda analogous to "default-deny" vs. "enumerating badness"...
I use this hack:
you can edit /etc/PackageKit/PackageKit.conf
And change "DefaultBackend=yum" to
Then PackageKit will not harm you any more
(In reply to comment #18)
> Then PackageKit will not harm you any more
PackageKit is not out to harm anybody - lets try not to make each other feel bad about the software we're working on.
Sorry for the bad wording, I have no problem with PK, I did most of the initial work on the yum backend ;)
I just don't like that I don't have a choice to remove it, if I don't wan't it and it get in the way of other tools. :)
This is also bugging OLPC. We're very limited for disk space, memory, and bandwidth, and due to the fact that our users are 6 year olds we take the whole "system update" thing out of their hands and invoke it automatically from the school server. So, removing PackageKit is the most attractive option for us (it was optional until recently at least).
Tim Lauridsen has posted a patch here a few months ago. Can we get a review on it?
It looks sensible to me - we'd just have to add this subpackage to comps.xml in the GNOME desktop group.
actually I would need a "global" PackageKit disable too, if not remove it.
Is it possible to configure something in /etc/PackageKit/PackageKit.conf (or elsewhere) in order to stop "packagekitd" once and for all?
(In reply to comment #22)
> Hi all,
> actually I would need a "global" PackageKit disable too, if not remove it.
> Is it possible to configure something in /etc/PackageKit/PackageKit.conf (or
> elsewhere) in order to stop "packagekitd" once and for all?
Not officially, but you can use the hack in comment #18
(In reply to comment #23)
> Not officially, but you can use the hack in comment #18
I saw that, but I was hesitating, since in my version of the "PackageKit.conf" there is no "DefaultBackend" entry.
Of course, maybe I could add one, but I was not sure if it would be correct.
(In reply to comment #24)
> Hi Tim,
> I saw that, but I was hesitating, since in my version of the
> "PackageKit.conf" there is no "DefaultBackend" entry.
> Of course, maybe I could add one, but I was not sure if it would be correct.
Just add one :)
Matthias: it appears reviewing the bug that splitting the plugin out to an updates subpackage and making gnome-packagekit depend on it would remove the dependency issue and not break gnome upgrades (unless they've removed that package, at which point it's broken anyway). Are you happy with that resolution or is there something else that has been missed?
gnome-settings-daemon-3.6.0-2.fc18, gnome-packagekit-3.6.0-2.fc18 has been submitted as an update for Fedora 18.
Package gnome-settings-daemon-3.6.0-2.fc18, gnome-packagekit-3.6.0-2.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing gnome-settings-daemon-3.6.0-2.fc18 gnome-packagekit-3.6.0-2.fc18'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Thanks for fixing this issue :)
Thank you for fixing it!
good news! Thanks!
How about F-17, will we get the update too?
> How about F-17, will we get the update too?
No, it won't happen. It's an unnecessary change to a stable release.
This has been pushed to stable