+++ This bug was initially created as a clone of Bug #1173107 +++ > 4. How does it look for Rawhide? > > $ ls -l /var/cache/dnf/x86_64/ > celkem 12 > drwxr-xr-x. 2 root root 4096 22. říj 15.31 21 > drwxr-xr-x. 5 root root 4096 26. úno 12.42 22 > drwxr-xr-x. 3 root root 4096 26. úno 12.51 23 > > Ah, 3 cache folders and they will just grow, but the repository was always > the same: > > $ cat /etc/yum.repos.d/fedora-rawhide.repo | grep repo=rawhide\& > metalink=https://mirrors.fedoraproject.org/ > metalink?repo=rawhide&arch=$basearch > > So why there are still versioned cache directories? This wastes precious > space on my test virtual machine :/ Yes, this may be a problem. Please, file a bug if you can.
OK, looking at the summary it seems that I might have misunderstood you. A thought that the problem is that if you have a repository that does not contain e.g. a $releasever variable, DNF downloads (and caches) the metadata for every different "--releasever" value if if it's unnecessary. Is you problem related only to rawhide? Why shouldn't DNF cache the rawhide metadata?
*I thought *even if it's unnecessary
The thing is that the $releasever changes during lifetime of rawhide. So you see that at 26th of February, it changed from 22 to 23. The cache was still valid. The content was still valid. The upstream repositoried did not changed. The $releasever is not used anywhere in the /etc/yum.repos.d/fedora-rawhide.repo but yet the cache become invalid. The DNF actually caches the data for "rawhide" repository in "rawhide" directory, but this repository specific directory is stored under $releasever directory. This is the whole content of my cache directory on Rawhide: $ find /var/cache/dnf/x86_64/ -type d /var/cache/dnf/x86_64/ /var/cache/dnf/x86_64/23 /var/cache/dnf/x86_64/23/x86_64 /var/cache/dnf/x86_64/23/x86_64/23 /var/cache/dnf/x86_64/23/x86_64/23/vondruch-doublecmd /var/cache/dnf/x86_64/23/x86_64/23/vondruch-doublecmd/repodata /var/cache/dnf/x86_64/23/x86_64/23/vondruch-doublecmd/packages /var/cache/dnf/x86_64/23/x86_64/23/rawhide /var/cache/dnf/x86_64/23/x86_64/23/rawhide/repodata /var/cache/dnf/x86_64/23/x86_64/23/rawhide/packages /var/cache/dnf/x86_64/22 /var/cache/dnf/x86_64/22/vondruch-doublecmd /var/cache/dnf/x86_64/22/vondruch-doublecmd/repodata /var/cache/dnf/x86_64/22/vondruch-doublecmd/packages /var/cache/dnf/x86_64/22/x86_64 /var/cache/dnf/x86_64/22/x86_64/22 /var/cache/dnf/x86_64/22/x86_64/22/vondruch-doublecmd /var/cache/dnf/x86_64/22/x86_64/22/vondruch-doublecmd/repodata /var/cache/dnf/x86_64/22/x86_64/22/rawhide /var/cache/dnf/x86_64/22/x86_64/22/rawhide/repodata /var/cache/dnf/x86_64/22/rawhide /var/cache/dnf/x86_64/22/rawhide/repodata /var/cache/dnf/x86_64/22/rawhide/packages /var/cache/dnf/x86_64/21
Oh, I see. OK, this is valid. This would require a substantial change in the DNF's caching mechanism. For the further consideration: On one side, there are repositories where we want to preserve cache for all $releasevers (e.g. Fedora), on the other side, there are repositories where we might not want this (e.g. Rawhide).
Heh, well, it's fairly simple. The repositories, where we want the "versioned cache", are those that contain some variables. Otherwise, we don't want the cache to be "versioned" :-)
Wouldn't be easier to make cache directories based on repo url hash (after variable expansion)? If name changes after variable substitution it leads into a different hash and the other way round if url stays unchanged even after substitution hash won't change and cache will be reused.
Yes, that might be one solution. I personally hate using hashes since they are not unique and (thus) they cannot be decoded which would make DNF more difficult to debug but that's just my opinion. On the other hand, base the cache on URLs is probably the best what we can do.
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
*** Bug 1211252 has been marked as a duplicate of this bug. ***
Changes in https://github.com/rpm-software-management/dnf/pull/309 removes releasever from cache path.