Bug 699348 - gnome-settings-daemon should not require PackageKit
Summary: gnome-settings-daemon should not require PackageKit
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-settings-daemon
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Bastien Nocera
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 699263 (view as bug list)
Depends On:
Blocks: depchain
TreeView+ depends on / blocked
 
Reported: 2011-04-25 09:54 UTC by Christoph Wickert
Modified: 2018-04-11 17:37 UTC (History)
28 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-10-09 14:38:07 UTC
Type: ---


Attachments (Terms of Use)
Patch to split the updates plugin in sub-package (3.18 KB, patch)
2011-12-20 11:34 UTC, Tim Lauridsen
no flags Details | Diff

Description Christoph Wickert 2011-04-25 09:54:23 UTC
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):
gnome-settings-daemon-2.91.93-2.fc15.i686

How reproducible:
always

Steps to Reproduce:
1. Boot F15 Beta Desktop live
2. # yum remove Packagekit
  
Actual results:
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.

Expected results:
Only a few packages should be removed, most important not gnome-settings-deamon.

Additional info:
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.

Comment 1 Christoph Wickert 2011-04-25 10:13:33 UTC
*** Bug 699263 has been marked as a duplicate of this bug. ***

Comment 2 Christoph Wickert 2011-04-26 10:45:19 UTC
(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.

Comment 3 Ilyes Gouta 2011-04-26 11:44:45 UTC
Hi,

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)?

-Ilyes

Comment 4 Matthias Clasen 2011-04-27 18:31:14 UTC
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 ...

Comment 5 Ilyes Gouta 2011-04-27 20:30:00 UTC
Hi Matthias,

> 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 ...

Alright, then!

So is this an agreement? Are we moving towards the resolution of this issue?

Thanks a lot,

-Ilyes

Comment 6 Matěj Cepl 2011-04-27 23:46:37 UTC
(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?

Comment 7 Matthias Clasen 2011-04-28 00:48:32 UTC
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...

Comment 8 Tim Lauridsen 2011-04-28 06:02:19 UTC
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.

Comment 9 Marcela Mašláňová 2011-04-28 06:30:59 UTC
(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
> place...

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...

Comment 10 Matthias Clasen 2011-05-04 13:16:09 UTC
'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.

Comment 11 Tim Lauridsen 2011-12-20 11:34:33 UTC
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.

Comment 12 Tim Lauridsen 2012-03-03 08:59:51 UTC
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.

Comment 13 Gabriel Somlo 2012-05-02 14:21:33 UTC
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... :)

Thanks,
--Gabriel

Comment 14 Rex Dieter 2012-05-02 14:25:17 UTC
you could just remove gnome-packagekit frontend too

Comment 15 Gabriel Somlo 2012-05-02 14:42:21 UTC
(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 :)

Comment 16 Christoph Wickert 2012-05-02 14:59:52 UTC
(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
> 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 ?

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).

Comment 17 Gabriel Somlo 2012-05-03 13:30:23 UTC
(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
> /etc/polkit-1/localauthority/(10-vendor.d,20-org.d,30-site.d).

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"...

Thanks,
--G

Comment 18 Tim Lauridsen 2012-05-03 13:44:38 UTC
@Gabriel:

I use this hack:

you can edit /etc/PackageKit/PackageKit.conf

And change "DefaultBackend=yum" to

DefaultBackend=GetOutOfMyFace

Then PackageKit will not harm you any more

Comment 19 Matthias Clasen 2012-05-03 16:11:53 UTC
(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.

Comment 20 Tim Lauridsen 2012-05-07 07:09:19 UTC
@Matthias:

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. :)

Comment 21 Daniel Drake 2012-05-15 20:32:14 UTC
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.

Comment 22 Piergiorgio Sartor 2012-07-07 13:46:49 UTC
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?

Thanks,

bye,

pg

Comment 23 Tim Lauridsen 2012-07-08 06:52:15 UTC
(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?
> 
> Thanks,
> 
> bye,
> 
> pg

Not officially, but you can use the hack in comment #18

Comment 24 Piergiorgio Sartor 2012-07-08 10:00:45 UTC
(In reply to comment #23)
[...] 
> Not officially, but you can use the hack in comment #18

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.

Thanks anyway,

bye,

pg

Comment 25 Tim Lauridsen 2012-07-08 16:55:09 UTC
(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 :)

Comment 26 Peter Robinson 2012-09-06 23:13:18 UTC
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?

Comment 27 Fedora Update System 2012-10-01 18:26:23 UTC
gnome-settings-daemon-3.6.0-2.fc18, gnome-packagekit-3.6.0-2.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/gnome-settings-daemon-3.6.0-2.fc18,gnome-packagekit-3.6.0-2.fc18

Comment 28 Fedora Update System 2012-10-01 20:04:19 UTC
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:
https://admin.fedoraproject.org/updates/FEDORA-2012-15161/gnome-settings-daemon-3.6.0-2.fc18,gnome-packagekit-3.6.0-2.fc18
then log in and leave karma (feedback).

Comment 29 Tim Lauridsen 2012-10-02 04:39:37 UTC
Thanks for fixing this issue :)

Comment 30 Ilyes Gouta 2012-10-02 09:32:34 UTC
Thank you for fixing it!

-Ilyes

Comment 31 Piergiorgio Sartor 2012-10-07 11:31:33 UTC
Hi all,

good news! Thanks!

How about F-17, will we get the update too?

Thanks again,

bye,

pg

Comment 32 Peter Robinson 2012-10-07 18:01:30 UTC
> How about F-17, will we get the update too?

No, it won't happen. It's an unnecessary change to a stable release.

Comment 33 Peter Robinson 2012-10-09 14:38:07 UTC
This has been pushed to stable


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