On 16 September 2015 at 18:46, Gordon Messmer <gordon.messmer@xxxxxxxxx> wrote: > Never was sure why; I thought that's what packagekitd was *for*. PackageKit needs to offer clients results with guaranteed latencies; it's no good if the command-not-found handler takes 700ms to return results, or gnome-software takes 15 seconds to show the first overview screen. This is why some of the fancier stuff was turned off with the yum backend. The problem with sharing a cache is that PackageKit downloads an entire set of repository files at the same time, all coherent to each other. It then atomically swaps the link in the cache so that at any time you can query PackageKit for results and get something sane in a small amount of time. What dnf does, and yum did, is download only the files that it needs. This is great for command line use where you might just want to check for updates, but means that we have metadata from different repositories with different ages, and most importantly different metadata files in the same repo with different ages (repo files reference each other internally). This means using dnf that you can do something like a search with no additional downloads, but when you come to install something it could be that half way through the depsolve it works out that the filelists isn't new enough and starts downloading a new metadata file, so it can re-depsolve and continue on to install. PackageKit can't do this, as we only promise network access during certain method calls, and we have strict latency requirements for some requests, where downloading at random points would shatter both promises. If PK and DNF could agree to download all metadata at a set time for all repositories and do an atomic switch that would be great, and we could certainly share a cache. Until then, it makes sense to have separate locations. What we can fix is downloading the same file twice in some cases, and in that case either squid helps, or CAShe can fix that in the longer term. Richard. -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
