(In reply to comment #0)
> On Fedora 15, trying to "yum remove PackageKit" causes the system to attempt
> removing up to 74 MB worth of software, including gdm, empathy, bluez and
> gnome-shell!!!! Which is pointless.

Sure, lots of applications are now using PackageKit, which is great.

> Is it *really* required to have PackageKit so deeply integrated and made an
> essential package on the system. AFAIK, it's essentially a helper and a
> front-end for yum, right?

No, it's much more than that. Checkout http://www.packagekit.org for more information.

> Is it possible to recover Fedora 14's lightweight dependencies set, for
> PackageKit?

No.

> It shouldn't right? AFAIK, PackageKit isn't specified as a new feature
> enhancement for Fedora 15
> (http://fedoraproject.org/wiki/Releases/15/FeatureList) so why making it so
> required?

PackageKit has been a core part of Fedora for quite a few releases, and has been a required dependency of GNOME for quite a few years now. If anything, expect that more applications will depend on PackageKit in the future, not less.

As a general note, you can't choose to just remove a specific core library in a Linux distro and expect things to work. If I decide all of a sudden I don't like libsoup, I shouldn't expect the distro to allow me to remove such a core dep and for everything to work correctly.

Richard.

*** Bug 694169 has been marked as a duplicate of this bug. ***

I think this is too bad.  PackageKit is great for single user machines but for those of us who use Fedora in a multi-user environment, for example we run Fedora on many machines in a computer lab setting, PackageKit doesn't make much sense.  We don't want users installing packages because the machines are all clones of each other and we want to keep them the same.  We also don't want users getting notices about updates because we install them from a centralized location and these notices just confuse and bother the users.

It is also not quite true that PackageKit has been required dependency for GNOME in the past.  Until very recently (see Bug 694169) the following would remove PackageKit in Fedora 14 quite effectively:  rpm -e `rpm -qa | grep -i packagekit`

I certainly support PackageKit in principal but I wish I had the option to remove it.

Why are these dependencies on PackageKit necessary?  It doesn't seem to me that ordinary applications should be trying to install packages.

Would it at least be possible to get some details about the PolicyKit rules and how to lock down/disable various PackageKit features on the PackageKit FAQ?  http://www.packagekit.org/pk-faq.html

If you google something like "packagekit disable" most people are saying to either remove it (which won't work anymore) or to change some settings in System -> Preferences -> Software Updates (which isn't system wide and doesn't really lock anything down).

I assume this will involve manually changing some settings in /var/lib/polkit-1 and setting some mandatory gconf entries?

That would be a great reference for those of us who use Fedora outside of a desktop setting.  Thanks!

(In reply to comment #1)
> (In reply to comment #0)
> > Is it possible to recover Fedora 14's lightweight dependencies set, for
> > PackageKit?
> 
> No.

I think this is not true. The root if this problem is having gnome-settings-daemon depend on PackageKit-glib and this can easily be changed as the dependency is only caused by a single plugin but not the settings daemon itself. The plugin should be part of gnome-packagekit since it is a GNOME frontend to PackageKit settings. If it really needs to be in gnome-settings-deamon it should be a sub-package. Filed as bug 6999348.

Sorry, bug 699348 in fact.

*** This bug has been marked as a duplicate of bug 699348 ***

Hi,

> The root if this problem is having gnome-settings-daemon depend
> on PackageKit-glib

Thanks Christoph for the analysis!

-Ilyes

(In reply to comment #5)
> The plugin should be part of gnome-packagekit since it is a GNOME
> frontend to PackageKit settings. If it really needs to be in
> gnome-settings-deamon it should be a sub-package.

It's in the upstream gnome-settings-daemon tarball.

Richard.

Hi Richard,

> It's in the upstream gnome-settings-daemon tarball.

Is it possible to fixup gnome-settings-daemon's spec file so that the updates plugin gets packaged in a dedicated subpackage, with the right PackageKit dependencies?

This it, right? :)

Thanks,

-Ilyes

(In reply to comment #9)
> Is it possible to fixup gnome-settings-daemon's spec file so that the updates
> plugin gets packaged in a dedicated subpackage, with the right PackageKit
> dependencies?

It depends if the gnome-settings-daemon maintainer wants the split up the package into numerous per-plugin sub-packages. It's certainly possible, but I'm not sure it's a good idea.

Richard

(In reply to comment #8)
> It's in the upstream gnome-settings-daemon tarball.

Because you added it. ;)

(In reply to comment #10)
> It depends if the gnome-settings-daemon maintainer wants the split up the
> package into numerous per-plugin sub-packages. 

Not numerous but a single sub-package.

> It's certainly possible, but I'm not sure it's a good idea.

You think having a hardcoded dependency on PackageKit is better? In this case a dep on PackageKit-glib is not enough because for proper GNOME integration we not only need a configuration plugin but also gpk-update viewer. Requiring packagekit-gnome however is definitely too much. Look at bug 699348: 6 people have added themselves as CC in less than 24 hours. Seems this dependency is causing many people headache.

Anyway, let's continue the discussion in bug 699348.

(In reply to comment #11)
> You think having a hardcoded dependency on PackageKit is better? In this case a
> dep on PackageKit-glib is not enough because for proper GNOME integration we
> not only need a configuration plugin but also gpk-update viewer. Requiring
> packagekit-gnome however is definitely too much. Look at bug 699348: 6 people
> have added themselves as CC in less than 24 hours. Seems this dependency is
> causing many people headache.

We're not making an OS that's a grab-bag of parts. Running gnome-packagekit without gnome-settings-daemon or gnome-control-center isn't supported. Running gnome-settings-daemon without PackageKit isn't supported either.

The desktop isn't just a random set of applications anymore, it's a spiders web of interconnected components. I really don't think the situation is going to get any better, in future releases we'll have more interconnected parts, not fewer.

Hi Richard,

> We're not making an OS that's a grab-bag of parts. Running gnome-packagekit
> without gnome-settings-daemon or gnome-control-center isn't supported.
> Running gnome-settings-daemon without PackageKit isn't supported either.

We, Fedora users/developers/contributors, define how a the distribution look like. If the consensus is to be a grab-bag, then yeah, let it be. Modularity is good too when well designed and implemented. And we do have the means and the tools to achieve it.

Are we restricting choice?

So far, and as far as I can understand, there are no real *technical* reasons that hinders re-establishing the correct setup, while keeping every one happy (including GNOME3 developers with the PackageKit agenda).

Please just take a step back and look at the big picture. Here is the question: how come doing a "yum remove gnome-packagekit" ends up stripping away gdm, bluez and gnome-shell? What's the relation between PackageKit, bluetooth and the login screen?

> Running gnome-settings-daemon without PackageKit isn't supported either.

Not supported?? The intersection of gnome-settings-daemon and PackageKit is a shared library called plugins/updates, an .so file!

-Ilyes

(In reply to comment #13)
> Are we restricting choice?

I hope we are. Please read http://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html

> Please just take a step back and look at the big picture. Here is the question:
> how come doing a "yum remove gnome-packagekit" ends up stripping away gdm,
> bluez and gnome-shell? What's the relation between PackageKit, bluetooth and
> the login screen?

In the same way, removing upower removes half the stack.

> > Running gnome-settings-daemon without PackageKit isn't supported either.
> 
> Not supported?? The intersection of gnome-settings-daemon and PackageKit is a
> shared library called plugins/updates, an .so file!

And schema. And if we make the plugins be added and removed at runtime, we have to support loading and unloading the schema work in apps that try to load that schema.

On a simpler point, intentionally making the desktop be
a "spiders web of interconnected components" is simply poor
engineering practice that will [more accurately "has" in the
case of GNOME] lead to poor quality software.

The strange thing is that the pk parts was removed from "System Settings" in upstream gnome3 because a updater is not considered a "System Setting".
But the gnome-settings-daemon plugin is still there and causing the issue
gnome-settings-daemon to require pk.
You can remove gnome-packagekit to remove all the gui parts of pk without problems and as far as I can see I will make the gnome settings plugin useless.
So as far as I can see there is no functional reason for having the gnome setting daemon plugin in the gnome-settings-daemon package, it should go into the gnome-packagekit or a separate package.
To give the user a choice to remove packagekit, if he/she wants to.
You can do it in F14 without any problems, so i dont see why you should not be able to do so in F15.

(In reply to comment #12)
> We're not   making an OS that's a grab-bag of parts. Running gnome-packagekit
> without gnome-settings-daemon or gnome-control-center isn't supported. Running
> gnome-settings-daemon without PackageKit isn't supported either.

What does supported mean in this context?
a) It doesn't work or
b) you don't want it because it does not fit into your "grand plan" like bug 485846?

> The desktop isn't just a random set of applications anymore, it's a spiders web
> of interconnected components. I really don't think the situation is going to
> get any better, in future releases we'll have more interconnected parts, not
> fewer.

It's not about the different parts being interconnected but about packaging them in a sane way.

(In reply to comment #14)
> (In reply to comment #13)
> > Are we restricting choice?
> 
> I hope we are. Please read
> http://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html

This thread was originally about a firewire camera and the problems were only temporarily during the juju migration. Nobody has a problem if choice is limited for a certain amount of time but this doesn't seem to be the case here.

> > Please just take a step back and look at the big picture. Here is the question:
> > how come doing a "yum remove gnome-packagekit" ends up stripping away gdm,
> > bluez and gnome-shell? What's the relation between PackageKit, bluetooth and
> > the login screen?
> 
> In the same way, removing upower removes half the stack.

Are you seriously comparing PackageKit to upower? PackageKit is a framework fir managing packages and there are lots of alternatives: yumex, yum, zypper, yast, apt, synaptic. All of them are doing their job and are actively maintained. How many alternatives to upower are out there and actively maintained?

> > Not supported?? The intersection of gnome-settings-daemon and PackageKit is a
> > shared library called plugins/updates, an .so file!
> 
> And schema. And if we make the plugins be added and removed at runtime, we have
> to support loading and unloading the schema work in apps that try to load that
> schema.

Does this have anything to do with what package provides the so and the schema? and does the plugin have any use without gpk-update-viewer?

(In reply to comment #17)
> What does supported mean in this context?
> a) It doesn't work or
> b) you don't want it because it does not fit into your "grand plan" like bug
> 485846?

Neither. I don't want to support an operating system made out of a grab bag of parts. We can barely support an OS made up of just packages on the livecd. GNOME is no longer a set of applications that can be treated in isolation.

> Does this have anything to do with what package provides the so and the schema?
> and does the plugin have any use without gpk-update-viewer?

Well, it checks for updates and launches a tool to view them. It will in the near future also download them and offer to install them on shutdown / restart. So gdm and maybe even systemd will be involved too. I'm guessing that might make you more angry (even more integration with other software) so I'm not sure there's much more point me trying to convince you that splitting things up is not a good idea.

Hi Richard,

> It will in the near future also download them and offer to install them
> on shutdown / restart.

Is this the grand plan?

How about users wanting to *control* the updates process?

> I'm guessing that might make you more angry (even more integration with
> other software

Man, I for one, it made me laugh out loud (in a friendly way) instead!

> so I'm not sure there's much more point me trying to convince you
> that splitting things up is not a good idea.

Not splitting software is the easy way out :) It means there are no well defined interfaces and protocols to handle most of the use-cases.

> It will in the near future also download them and offer to install them
> on shutdown / restart.

Obviously you're not targeting Fedora 15 here, is it?

When would this be ready, i.e the time-frame and release target?

Also, and this just out of curiosity, could you please point out who and how decision are taken, that's to define new features, deployment procedure, and then inclusion in this or that release?

Thanks,

-Ilyes

(In reply to comment #19)
> Is this the grand plan?

Well, it's *one* plan. I'm not sure it qualifies to be grand.

> Obviously you're not targeting Fedora 15 here, is it?

Well, we were targeting GNOME 3.0, but we ran out of time. Now we're targeting 3.2, so F-16. A lot of the code is already in place, just not wired up.

> Also, and this just out of curiosity, could you please point out who and how
> decision are taken, that's to define new features, deployment procedure, and
> then inclusion in this or that release?

The design team have worked quite a bit on this -- see https://live.gnome.org/GnomeShell/Design/Whiteboards/SystemStopRestart for the install-updates-on-shutdown feature.

Richard.

Richard,

> Well, we were targeting GNOME 3.0, but we ran out of time. Now we're
> targeting 3.2, so F-16. A lot of the code is already in place, just not
> wired up.

Alright, how about wiring things up once they're *really* ready? Is GNOME 3.2 ever going to ship during Fedora 15's first 6 months?

Your target is Fedora 16, not Fedora 15.

This would save users more time to express their position and drive the discussion in GNOME3 upstream, and you (and developers) to adopt the suitable design and implementation.

I believe Christoph Wickert already proposed moving the updates plugin to PackageKit-gnome instead of keeping it under gnome-settings-daemon (Am I right? :P). Tim Lauridsen seconded him and confirms. This would be valid even for GNOME3.2, keeping everyone happy.

Now, let's go back to our issue: at its core it's just a small packaging detail. Let's start by the sub-package approach then see what could happen with the upstream folks.

Richard, don't worry about the "spiders web of interconnected components". We'll go there, but please in consensus, in concert.

> The design team have worked quite a bit on this -- see
> https://live.gnome.org/GnomeShell/Design/Whiteboards/SystemStopRestart
> for the install-updates-on-shutdown feature.

Interesting, thanks for the pointers!

-Ilyes

(In reply to comment #21)
> I believe Christoph Wickert already proposed moving the updates plugin to
> PackageKit-gnome instead of keeping it under gnome-settings-daemon (Am I right?
> :P). Tim Lauridsen seconded him and confirms. This would be valid even for
> GNOME3.2, keeping everyone happy.

It's in the gnome-settings-daemon tarball.

Richard.

(In reply to comment #22)
> (In reply to comment #21)
> > I believe Christoph Wickert already proposed moving the updates plugin to
> > PackageKit-gnome instead of keeping it under gnome-settings-daemon (Am I right?
> > :P). Tim Lauridsen seconded him and confirms. This would be valid even for
> > GNOME3.2, keeping everyone happy.
> 
> It's in the gnome-settings-daemon tarball.
> 
> Richard.

Then make a gnome-settings-plugin-packagekit subpackage in the gnome-settings-daemon spec and make gnome-packagekit require that.

Then you i will be possible to remove PackageKit without removing gdm, gnome-shell, etc.

It will break nothing and if gnome-packagekit is removed, then packagekit gnome-settings plugin can't do anything.

The idea to make a plugin infrastructure is to make make it possible to extend the system and give the users the choice to select what special features they want.

Aren't you all missing the point?

All that's needed is a way to switch the thing off. 

I do manual updates and I constantly clash with PackageKit. Also, it uses a lot of resources when it runs.

Some sort of configuration switch to simply turn it off would be nice.

(In reply to comment #24)
> All that's needed is a way to switch the thing off. 

How would that work? What if abiword called into PK to install a dictionary? Would we show the user a dialog saying "Can't do that"? What about when totem tries to install a mp3 decoding plugin, or evince a font?

If you just want to turn off the PackageKit yum integration, just remove the PackageKit-yum-plugin package.

Richard

That's for the developers to work out, so the system is usable for not so technically literate people. 

Dare I say, Windose would have some graphical entry you could drag up to allow you to uncheck a box so packagekit doesn't run every 10 minutes.

I googled this problem. I found a lot of forum entries where people were asking about the very problem I had with packagekit. Only one of the 20 or so answers I looked answers said the problem could be solved by disabling the yum plugin.

(In reply to comment #25)
> 
> How would that work? What if abiword called into PK to install a dictionary?
> Would we show the user a dialog saying "Can't do that"? What about when totem
> tries to install a mp3 decoding plugin, or evince a font?

It should be noticed that PK was intentionally removed for this case. So, "can't do that: please install PackageKit" would be a desired behaviour, IMHO.

There are some cases when users are not expected to manage packages (it is the administrator's job). And more generally, there are the cases when yum is enough and there is no need in packet managing GUI.