On Dec 11, 2016 9:00 PM, "Chris Murphy" <lists@colorremedies.com> wrote:
On Sun, Dec 11, 2016 at 3:10 PM, Neal Gompa <ngompa13@gmail.com> wrote:
> On Fri, Dec 9, 2016 at 5:58 PM, Matthew Miller <mattdm@fedoraproject.org> wrote:
>> On Fri, Dec 09, 2016 at 10:22:44PM +0000, Peter Robinson wrote:
>>> repo data). The full list makes up most of the 40Mb downloaded. The
>>> dnf developers seem to think that everyone has lots of data/bandwidth
>>> and don't see the problem with it.
>> Isn't the problem that the SAT solver used by DNF for dependency
>> resolution doesn't know in advance if it will be needed or not, and
>> there isn't an easy way of adding it in midway?
> This is correct. While it is possible to omit the data, the solver
> will then generate unsolvable solutions in some cases, as well as not
> be able to install using file paths, as there's no easy path to
> identify that you're just missing data vs not having a solution at
> all.
> That being said, there was some work on a prototype to make it so our
> metadata downloads didn't suck so bad[1][2]. However, I've not seen
> any progress on developing this and integrating it into createrepo_c
> and libdnf for PackageKit and DNF. This would be an excellent way to
> make our larger metadata much more tolerable for all kinds of
> environments. Maybe it might become important and be revived soon?
> [1]: https://github.com/rh-lab-q/deltametadata-prototype
> [2]: https://github.com/rh-lab-q/deltametadata-prototype/wiki/Deltametadata-of-repo-md-files

The other issue is that dnf and PackageKit each download their own
copies of this metadata. Delete /var/cache/dnf and
/var/cache/PackageKit, reboot and within a couple hours du will show:

108M    dnf
132M    PackageKit

My hope is that this issue can be addressed before Fedora 26 releases. The necessary pieces of the puzzle to unify at least the cache are in place in Rawhide now. One of the DNF developers can further elaborate on this, though.