dnf cache downloading behavior

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Is this expected behavior? Or is it a bug? And if it's a bug, how do I
collect the necessary information for a bug report? This problem
happens often, but not every day.



[chris@f26h Downloads]$ sudo dnf install *rpm
Fedora 26 - x86_64 - Test Updates

534 kB/s |  24 MB     00:46
Fedora 26 - x86_64 - Updates

570 kB/s | 6.6 MB     00:11
google-chrome

53 kB/s | 3.8 kB     00:00
Last metadata expiration check: 0:00:00 ago on Sat 22 Jul 2017 10:05:21 AM MDT.
Dependencies resolved.

And then in another Terminal tab hardly 25 minutes later it wants to
download the exact same repo metadata again. Why?


[chris@f26h Downloads]$ dnf search openjpeg
Fedora 26 - x86_64 - Test Updates

572 kB/s |  24 MB     00:43
Fedora 26 - x86_64 - Updates

567 kB/s | 6.6 MB     00:11
Fedora 26 - x86_64

554 kB/s |  53 MB     01:38
google-chrome

52 kB/s | 3.8 kB     00:00
Last metadata expiration check: 0:00:00 ago on Sat 22 Jul 2017 10:32:55 AM MDT.


This doesn't always happen, I can't reproduce it on demand. But it'll
download metadata 4-5 times a day sometimes.

OK let's move over to a different system:

[chris@f26s ~]$ dnf search -C  openjpeg
Last metadata expiration check: 24 days, 16:37:49 ago on Tue 27 Jun
2017 06:05:35 PM MDT.
[snipresults]

24 days? Huh?

Jul 20 08:21:49 f26s.localdomain systemd[1]: Starting dnf makecache...
Jul 20 08:21:50 f26s.localdomain dnf[7709]: Metadata cache refreshed recently.
Jul 20 08:21:50 f26s.localdomain systemd[1]: Started dnf makecache.

Nope. It's maybe two days old. And when I 'ls -l /var/cache/dnf' all
items are July 19 or 20. But then.

[chris@f26s ~]$ dnf search -Cv  openjpeg
Loaded plugins: builddep, config-manager, copr, debug,
debuginfo-install, download, generate_completion_cache,
needs-restarting, playground, repoclosure, repograph, repomanage,
reposync, system-upgrade
DNF version: 2.5.1
cachedir: /var/tmp/dnf-chris-2qrmnhfh
repo: using cache for: updates-testing
updates-testing: using metadata from Tue 27 Jun 2017 01:53:53 PM MDT.
repo: using cache for: updates
not found deltainfo for: Fedora 26 - x86_64 - Updates
not found updateinfo for: Fedora 26 - x86_64 - Updates
updates: using metadata from Wed 08 Mar 2017 09:31:02 PM MST.
repo: using cache for: fedora
not found updateinfo for: Fedora 26 - x86_64
fedora: using metadata from Tue 27 Jun 2017 06:32:42 AM MDT.
Last metadata expiration check: 24 days, 16:40:42 ago on Tue 27 Jun
2017 06:05:35 PM MDT.
Searching Packages:

And then

[chris@f26s ~]$ ls -l /var/tmp/dnf-chris-2qrmnhfh

And sure enough there's a bunch of repo database files, same as in
/var/dnf/cache that are all dated from June.

WTH? Why is dnf using 24 day old stale repo data in /var/tmp when
there's newer data in /var/dnf/cache? Why does dnf have two cache
locations in the first place? Oh I guess no there's three, it's got an
empty directory in /tmp as well that maybe it uses for staging, no
idea.

?!

-- 
Chris Murphy
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux