disabling packagekit

[tho.mei]

PackageKit (Apper) is a software we don't use at all, Yumex and a cron-job does a much better job.

Since a few years I'm searching for a solution to stop the PackageKit-Deamon from running. It feeds resources that we could need in other ways better. You can disable the functionality of PackageKit. That works. But it still stars up the daemon. (I've never ever seen a such strange daemon on UNIX!)

Deinstalling PackageKit would be the best solution. But since F15 there are dependencies to PackageKit are everywhere. (What an unnecessary mess the developers! It seems the developers did a really worse job.)

I found an new try to fix thys: http://posix.in-egypt.net/content/ho...ing-packagekit But it seems not really to disable packagekitd.

Are there some other solutions?

[RupertPupkin]

What do you have installed that depends on PackageKit? On my F16 system I don't have any PackageKit packages installed. Then again, I don't use KDE or GNOME.

[tho.mei]

See the attachment for all the dependencies:

[sonoran]

One way to see if those are real dependencies is to remove packagekit using rpm -e with the --nodeps option and see if anything breaks.

[fibster]

Package kit is just another synaptic really imo, i would use yum instead of trying the rpm to remove any packages, yum tracks.

Also where is package kit tying up resources for you? I have a meager 2 gb ram and looking at my processes I see no package kit running?

linux like windows manages ram and memory so well i haven't noticed any problems like in years past.

by the way this should work if you really want to stop packagekitd,

systemctl disable packagekitd.service

[tho.mei]

Package kit is just another synaptic really imo, i would use yum instead of trying the rpm to remove any packages, yum tracks.

Thanks, I know what PackageKit, yum and rpm is. That’s not the questions.
You are right. If you do rpm -e, you are no longer able to use yum properly. You would end with a lot of unsolvable dispenses each time the update runns.

Also where is package kit tying up resources for you? I have a meager 2 gb ram and looking at my processes I see no package kit running?

Not all our customers are blessed with 2GB RAM! Packagekitd starts each day once. It feeds network packagekitd. This is really a problem if you run 100+ Fedora boxes at once. The second problem is: packagekitd blocks yum for hours sometimes. Which means our own software rollout system (a tiny) or the administrator can't use yum.

linux like windows manages ram and memory so well i haven't noticed any problems like in years past.

You may never did run a scientific simulation. It really needs all the resources. And windows is in this case a slow system compared to F16. We are not home user! Each hour and minute of calculation time is money.

by the way this should work if you really want to stop packagekitd, systemctl disable packagekitd.service

Wrong: packagekitd is started by dbus. It starts on some system status. (It means no actions of the user… low network traffic…) Because it isn't a normal UNIX daemon, it's so hard to stop. If it would be started by systemd or cron, as it should be, it would be really easy to stop it from starting. What the developers thought by starting a daemon by debus, I still wondering.

[aesir]

Looking at the dependency chain the culprit is phonon-backend-gstreamer

It is already reported here since f14: https://bugzilla.redhat.com/show_bug.cgi?id=694169

The answer is: desktop users need this to auto-magically install codecs to play their fancy media files, fedora is a desktop distro, so f*** you we need that dependency.

If it works for you replace phonon-backend-gstreamer with phonon-backend-xine

BTW for your scientific simulations you don't need kde4, just free those 557 M and install some lightweight DE

[tho.mei]

I'll try to replace the phonon-backend. Good idea. Thanks!

BTW for your scientific simulations you don't need kde4, just free those 557 M and install some lightweight DE

How true, if it comes to the calculation it self. To have KDE installed doesn’t means to run it while calculating. We use RL 3 for the calculation. But before the calculation, the user needs to do a lot of graphical staff on the same boxes. Because we need to offer some confortable desktop to the end user.

---------- Post added at 02:37 PM ---------- Previous post was at 12:22 PM ----------

https://bugzilla.redhat.com/show_bug.cgi?id=694169

The lastest post (2011-11-22 10:56) there sounds like in F17 the problem will be solved...

But I still need to solve it in F16

[smr54]

https://bugzilla.redhat.com/show_bug.cgi?id=699263 has an interesting dialog about this.

However, I find that, once again, avoiding Gnome and KDE saves me this problem. (I realize that in writing, that sounds as if I'm being smug, and I may be, a little.)

I also realize it's not practical for you to suddenly try to re-educate your users and take away KDE. I have no idea about LXDE, XFCE, or any of the other desktop environments, but apparently, having installed several window managers on a test machine, it seems to not be a problem. That is, I haven't installed XFCE or LXDE, but I did install several window managers (as opposed to desktop environments), such as fluxbox, openbox, dwm, evilwm, and, I think, a couple of others that I was trying, and none brought in packagekit.

[William Haller]

It wasn't completely clear in an earlier response where you mentioned that you roll out software yourself for your boxes. If you run your own local repository and point all the boxes local, it would at least speed up the individual boxes yum queries until you get the package kit issue resolved. You could also increase their metadata holding time so it doesn't expire as fast so they didn't look as often.

[aesir]

[/COLOR] The lastest post (2011-11-22 10:56) there sounds like in F17 the problem will be solved...

But I still need to solve it in F16 [/QUOTE]

I looked in koji; the only difference is in the packages is in the spec file.
As you can see they "resolved" dropping the dependency and nothing more.

--- phonon-backend-gstreamer.spec       2011-11-09 20:23:14.000000000 +0100
+++ phonon-backend-gstreamer.spec.f17   2011-11-15 18:35:39.000000000 +0100
@@ -3,7 +3,7 @@
 Name:    phonon-backend-gstreamer
 Epoch:   2
 Version: 4.5.90
-Release: 3%{?dist}
+Release: 4%{?dist}
 Group:   System Environment/Libraries
 License: LGPLv2+
 URL:     http://phonon.kde.org/
@@ -39,7 +39,7 @@
 Requires: gstreamer-plugins-good
 # not *strictly* required, but strongly recommended by upstream when built
 # with USE_INSTALL_PLUGIN
-Requires: PackageKit-gstreamer-plugin
+#Requires: PackageKit-gstreamer-plugin
 Requires: phonon%{?_isa} => %{phonon_version}
 Requires: qt4%{?_isa} >= %{_qt4_version}
 
@@ -94,6 +94,9 @@
 
 
 %changelog
+* Tue Nov 15 2011 Rex Dieter <rdieter@fedoraproject.org> 2:4.5.90-4
+- drop hard dep on PackageKit-gstreamer-plugin
+
 * Tue Oct 04 2011 Rex Dieter <rdieter@fedoraproject.org> 2:4.5.90-3
 - Obsoletes: phonon-backend-xine < 4.5.0

You can download the f17 srpm from koji
http://koji.fedoraproject.org/koji/b...buildID=274223
and "rpmbuild --rebuild" it

[tho.mei]

The problem is solved. Tanks to rpmfusion.

There is no longer a phonon-backend for xine. But we ship vlc and use the rpmfusion repo. There was a phonon-backend for vlc. It works more stable the gstreamer and it includes no dispenses to PackageKid!

We could remove PackageKid!

Thanks to everybody how did try to help!

[kilolima]

so for those of us who prefer to use yum on the commandline but can't because PK keeps running, but also want to use media software, how can it be removed? PK has dependency hooks in everything...

[talonx]

so for those of us who prefer to use yum on the commandline but can't because PK keeps running, but also want to use media software, how can it be removed? PK has dependency hooks in everything...

The brute force way I use is

<kill all packagekit processes>
and then
rm -rf /usr/libexec/packagekitd

Upgrades bring it back, though

[fonya]

Thank You talonx! This is, what is really working!