Description of problem: PackageKit is a service and should be run from rc?.d so it can be enabled and disabled by standard means. Version-Release number of selected component (if applicable): I don't want PackageKit running. Standard way to turn off a service is using "service" and "chkconfig" but the PackageKit daemon is started by some other means and it is not obvious how to turn it off other than uninstalling the package and its deps (which is what I ended up doing). IMHO this is a bug in the package, but at the least it is a bug in the documentation of the package.
PackageKit just isn't designed as a rc?.d service. It is only run when required, and then exits after a short delay. If you want to disable it, just untick the PackageKit applet in the session startup capplet, and remove/disable the yum-packagekit yum plugin. It won't start if nothing uses it. It is certainly not a bug in the package.
>PackageKit just isn't designed as a rc?.d service. I guess that was my point. If it were then it could be disabled and enabled when desired. It is an simple change -- just have it check existence of a file before running and have the init.d script create or delete that file. >It is only run when >required, and then exits after a short delay. Same is true for several rc?.d services. > If you want to disable it, just untick the PackageKit applet in the session > startup capplet, and remove/disable the yum-packagekit yum plugin. It won't > start if nothing uses it. You can't seriously think that finding that tick in session-startup capplet and some obscure files to remove/replace is a user-friendly way of switching this service off/on? > It is certainly not a bug in the package. ??
(In reply to comment #2) > It is an simple change -- just have it check existence of a file > before running and have the init.d script create or delete that file. No, it doesn't work like that. packagekitd is not a service, it's a reusable helper running as root. init.d services have to be lifecycle managed by upstart now anyway. > Same is true for several rc?.d services. Which ones? > You can't seriously think that finding that tick in session-startup capplet and > some obscure files to remove/replace is a user-friendly way of switching this > service off/on? Well, that stops the session service, but does not disable other applications using PackageKit to install fonts and codecs and that sort of thing. The "user friendly" solution is not to disable PackageKit, sorry.
>> Same is true for several rc?.d services. > > Which ones? anacron (third in `ls /etc/init.d/*`). >> You can't seriously think that finding that tick in session-startup capplet and >> some obscure files to remove/replace is a user-friendly way of switching this >> service off/on? > > Well, that stops the session service, but does not disable other applications > using PackageKit to install fonts and codecs and that sort of thing. > Point taken. But I'm still confused. You say to disable session service I untick the session-startup capplet and disable or remove the yum-packagekit plugins. I can do that? Why is yum-packagekit a dependency of PackageKit then? > The "user friendly" solution is not to disable PackageKit, sorry.
(In reply to comment #4) > Point taken. But I'm still confused. You say to disable session service I > untick the session-startup capplet and disable or remove the yum-packagekit > plugins. I can do that? Why is yum-packagekit a dependency of PackageKit then? Well, I assumed you didn't want the daemon starting up. The way yum-packagekit works is that after every manual transaction (e.g. yum update hal) it send a DBUS message to PackageKit telling it to flush caches and possibly update any icons with new state. If you disable this plugin and the session process, then the daemon really never has to wake up at all.