Bug 80053 - PackageKit rpm packages cache folder never cleaned
Summary: PackageKit rpm packages cache folder never cleaned
Alias: None
Product: PackageKit
Classification: Unclassified
Component: General (show other bugs)
Version: unspecified
Hardware: Other All
: medium major
Assignee: Richard Hughes
QA Contact:
URL: https://bugzilla.redhat.com/show_bug....
: 95107 (view as bug list)
Depends on:
Reported: 2014-06-15 15:41 UTC by Jean-François Fortin Tam
Modified: 2018-08-21 18:00 UTC (History)
22 users (show)

See Also:
i915 platform:
i915 features:


Description Jean-François Fortin Tam 2014-06-15 15:41:57 UTC
So we have /var/cache/yum, /var/cache/dnf and /var/cache/PackageKit which use a lot of space, but the triplication issue is bug #75327 I suppose.

However, something weird is still going on on my Fedora 20 + GNOME 3.10 machine.

GNOME warned me my disk is full again so I did a "yum clean all".

Later, I looked through Baobab and found out that /var/cache/PackageKit/metadata/updates/packages/ is eating 700 MB with 261 RPM packages, and yet all my updates have been applied for a while already. There are package files in there that go back to the month of March (~3 months ago). So it seems like for some reason, on my 3.10 machine the packagekit cache is never cleaned... how can I troubleshoot this?
Comment 1 Jean-François Fortin Tam 2014-06-15 15:44:08 UTC
It should be noted that I try to refrain from using yum and try to use dnf as much as possible (to avoid the cache triplication etc.)
Comment 2 Richard Hughes 2014-06-23 16:57:26 UTC
Is it plausible you used dnf to manually update the system after gnome-software had already downloaded them and prepped them ready for an offline update?
Comment 3 Jean-François Fortin Tam 2014-06-24 00:30:00 UTC
Very much possible yes, I use dnf update (and previously yum update) all the time to force apply all updates without restarting, because I can't be bothered to restart more than once a month (sorry: getting me to shut down all my apps and close all my documents is a very expensive operation!).

I would love if there was a way in gnome-software to apply normal updates (that don't require a restart) immediately, but I don't hold much hope of that being an accepted usecase :)
Comment 4 Jean-François Fortin Tam 2015-12-17 05:50:43 UTC
This is still an issue in Fedora 23 with a pure DNF system, with that cache folder weighing about a gigabyte or two merely a month after a clean install of Fedora, urgh...
Comment 5 Bernardo Donadio 2016-02-28 12:12:23 UTC
I confirm this behavior is still present in a fully updated Fedora 23. Just had to manually delete about 3GiB of RPM packages from the PackageKit cache folder.
Comment 6 bbk 2016-03-02 13:44:39 UTC
I am also affected of this bug. I wasn't happy in manually removing the files and i figured that with the following command the cache get cleaned:

pkcon refresh force -c -1

As for now i add a daily cronjob doing the work on our ~300 computers.
Comment 7 Paviluf 2016-07-02 21:04:15 UTC
(In reply to Richard Hughes from comment #2)
> Is it plausible you used dnf to manually update the system after
> gnome-software had already downloaded them and prepped them ready for an
> offline update?

Richard could it be possible to add a button in Gnome Software to clear the cache please ? That's it indeed that keep the cached packages in /var/cache/PackageKit. With dnf, for instance, we can do "dnf clean all" to delete all the caches but there is no equivalent in Gnome Software.

It's really something that can be useful for people like me that use a Chromebook that has just 16GB with Fedora. Right now one of the first thing I do on a clean install is to disable Gnome Software to download updates. Maybe that will help some of you guys :

$ gsettings set org.gnome.software download-updates false

Thanks !
Comment 8 Christophe Fergeau 2016-07-06 12:54:06 UTC
Would it be possible to even do that automatically, ie when checking for new updates to apply, also check for 'obsolete updates', ie cached packages which are no longer relevant because they were updated behind gnome-software's back?
Comment 9 Paviluf 2016-07-14 17:41:52 UTC
I opened a bug report for Gnome Software

Comment 10 Jean-François Fortin Tam 2016-10-14 00:27:00 UTC
My stupid and ugly attempt to "fix" this from the user's standpoint is:

rm -R /var/cache/PackageKit/*
chmod ugo-rwx /var/cache/PackageKit/

I'm not sure it actually works in practice, as I rediscover this bug every few months, but possibly because I forget to apply my "fix" after a clean install, or maybe package updates reset those permissions.

The more radical way (which I can only reasonably use on my own computers, not those I maintain for other people) is to probably just remove the "PackageKit" package entirely (which in turns removes GNOME Software etc.), sadly. I would rather not have to do that.
Comment 11 Bastien Nocera 2017-07-16 12:11:54 UTC
I had to remove F23, F24 and F25 packages from that directory to upgrade to F26 beta recently. PackageKit should really be able to know which files are current and which aren't.
Comment 12 Sam Tuke 2017-07-16 13:52:19 UTC
I also experience this problem periodically when the root partition fills up and gigabytes of outdated cached data have to be manually deleted.
Comment 13 fede@inventati.org 2017-11-23 05:39:58 UTC
I suggest anybody stumbling on this issue to read the discussion in this issue (already in the header, but some may miss it):
Comment 14 Carwyn Edwards 2018-01-29 12:56:37 UTC
*** Bug 95107 has been marked as a duplicate of this bug. ***
Comment 15 Carwyn Edwards 2018-01-29 13:12:26 UTC
Does this happen with any of the other backends? Do they also have a PackageKit cache distinct from the native package manager?
Comment 16 Richard Hughes 2018-08-21 15:52:16 UTC
We moved the upstream bugtracker to GitHub a long time ago. If this issue still affects you please re-create the issue here: https://github.com/hughsie/PackageKit/issues
Sorry for the impersonal message, and fingers crossed your issue no longer happens. Thanks.
Comment 17 Michael Catanzaro 2018-08-21 17:58:53 UTC
Note this has been reopened at https://bugzilla.redhat.com/show_bug.cgi?id=1306992.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.