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?
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.)
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?
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 :)
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...
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.
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.
(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
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?
I opened a bug report for Gnome Software
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.
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.
I also experience this problem periodically when the root partition fills up and gigabytes of outdated cached data have to be manually deleted.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.