Re: dnf cache downloading behavior
Dne 22.7.2017 v 23:26 Neal Gompa napsal(a): > On Sat, Jul 22, 2017 at 5:11 PM, Zbigniew Jędrzejewski-Szmek > wrote: >> On Sat, Jul 22, 2017 at 02:06:42PM -0600, Chris Murphy wrote: >>> On Sat, Jul 22, 2017 at 1:57 PM, Matthew Miller >>> wrote: On Sat, Jul 22, 2017 at 01:42:11PM -0600, Chris Murphy wrote: > I don't know what things the unprivileged user can do other than > search and info. But off hand I'd say an unprivileged user should not > be able to download metadata. Use one /var/cache/dnf always. And if > it's stale, just inform the user. Only update the cache if the command > is issued by root. I dunno; what harm is there in giving the ability to use a separate user cache for queries? This allows you to do things like repoquery as an unprivileged user for repos that aren't enabled by default. >>> I'm fine with a layered approach, *if* a repo db does not exist for >>> root, then it's OK for a user copy to be downloaded, but how about one >>> for all users to share rather than each user getting a downloaded copy >>> of the same thing? >> It'd probably require rearchitecturing the way that caching works. >> Current implementation does the best (maybe ignoring some minor bugs) >> of what is possible in a secure way with unprivileged users in current >> design, but we should be able to do better. Namely, create a polkit-aware >> daemon which will download metadata on demand, and then make root and >> the users forward all metadata download requests to this daemon. >> This would avoid any duplicate downloads, without the need to run >> dnf searches as root. >> >> (Ideally, dnf would also have strong tmpfiles.d policy to clean up all >> caches after ~1 month of unuse, so that if a user requests some repo, >> the disk space is not permanently wasted.) >> > So... like dnfdaemon, except with less capabilities? > > I already proposed it to DNF upstream while ago due to different use case: https://bugzilla.redhat.com/show_bug.cgi?id=1382224#c15 Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: dnf cache downloading behavior
On Sat, Jul 22, 2017 at 01:42:11PM -0600, Chris Murphy wrote: > On Sat, Jul 22, 2017 at 1:03 PM, Matthew Miller > wrote: > > On Sat, Jul 22, 2017 at 11:25:48AM -0600, Chris Murphy wrote: > >> > Here you aren't root so it's not using the same cache, because it can't > >> > write to the root owned cache so it creates a temporary cache owned by > >> > your > >> > user. > >> Oh. My. God. It makes complete sense, but is also completely > >> ridiculous. What a bad user experience. > > > > It seems like it would be completely reasonable for DNF to use the root > > cache if it's considered "fresh" by the current configuration. And > > actually, possibly even if it's not with a warning that the data might > > be out of date, with a flag required if you really want to download the > > metadata as a regular user. > > I don't know what things the unprivileged user can do other than > search and info. ‘dnf download’, for one. > But off hand I'd say an unprivileged user should not > be able to download metadata. Use one /var/cache/dnf always. And if > it's stale, just inform the user. Only update the cache if the command > is issued by root. Please don't do this, as it will break supermin & libguestfs, and we worked with dnf upstream in the first place to make ‘dnf download’ work sensibly for non-root users. Rich. > Multiple user machines, would each cause separately downloaded copies > into /var/tmp/dnf as well? > > And then, dnf make cache timer is only keeping the /var/cache/dnf copy > up to date. So the user copy is always going stale anyway. > > It's just... I don't see how this is worth it even with a fast > internet connection. > > > > -- > Chris Murphy > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: dnf cache downloading behavior
On 22/07/17 22:54, Matthew Miller wrote: > On Sat, Jul 22, 2017 at 02:06:42PM -0600, Chris Murphy wrote: >>> I dunno; what harm is there in giving the ability to use a separate >>> user cache for queries? This allows you to do things like repoquery as >>> an unprivileged user for repos that aren't enabled by default. >> I'm fine with a layered approach, *if* a repo db does not exist for >> root, then it's OK for a user copy to be downloaded, but how about one >> for all users to share rather than each user getting a downloaded copy >> of the same thing? > > How? Setuid downloader? Or make it world-writable? Seems sketchy. > >>> H. The `dnf -C` (or --cacheonly) flag does not seem to work as >>> documented. It says: > [...] >> Yep I've hit this also. > > Once this is fixed, I'm going to `alias dnf='dnf -c'` in my own user > account. Careful there. '-c', lowercase, specifies the config file. Make sure it's the uppercase '-C'. (On barely tangential note, dang, I miss yum aliases capability.) -- J. Randall Owens | http://www.GhiaPet.net/ signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: dnf cache downloading behavior
On Sat, Jul 22, 2017 at 10:02:49PM -0400, Neal Gompa wrote: > > Hmmm -- is it a long-running daemon or is it socket activated? > It's a D-Bus activated service. So, it's like socket activated, except > it occurs when something makes a D-Bus call to the daemon. Err, yes, that's what I meant to type. :) That's pretty cool, then. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: dnf cache downloading behavior
On Sat, Jul 22, 2017 at 9:05 PM, Matthew Miller wrote: > On Sat, Jul 22, 2017 at 11:36:29PM +, Zbigniew Jędrzejewski-Szmek wrote: >> > So... like dnfdaemon, except with less capabilities? >> Exactly! How do I use dnfdaemon? I only see the raw python and dbus APIS... >> Are there any plans to make dnfdaemon a primary method of interacting >> with dnf db? > > Hmmm -- is it a long-running daemon or is it socket activated? > It's a D-Bus activated service. So, it's like socket activated, except it occurs when something makes a D-Bus call to the daemon. It's currently used by dnfdragora (which has Qt, GTK+, and ncurses UIs) and yumex-dnf (which only has a GTK+ UI). There's no particular reason for it to be functionally separate from DNF itself. Well, except that it currently is... That said, the daemon's APIs are far less raw than DNF's own APIs, so it's much easier to build things on top of it. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: dnf cache downloading behavior
On Sat, Jul 22, 2017 at 11:36:29PM +, Zbigniew Jędrzejewski-Szmek wrote: > > So... like dnfdaemon, except with less capabilities? > Exactly! How do I use dnfdaemon? I only see the raw python and dbus APIS... > Are there any plans to make dnfdaemon a primary method of interacting > with dnf db? Hmmm -- is it a long-running daemon or is it socket activated? -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: dnf cache downloading behavior
On Sat, Jul 22, 2017 at 3:54 PM, Matthew Miller wrote: > On Sat, Jul 22, 2017 at 02:06:42PM -0600, Chris Murphy wrote: >> > I dunno; what harm is there in giving the ability to use a separate >> > user cache for queries? This allows you to do things like repoquery as >> > an unprivileged user for repos that aren't enabled by default. >> I'm fine with a layered approach, *if* a repo db does not exist for >> root, then it's OK for a user copy to be downloaded, but how about one >> for all users to share rather than each user getting a downloaded copy >> of the same thing? > > How? Setuid downloader? Or make it world-writable? Seems sketchy. Unprivileged writes for any user goes in /var/tmp/dnf rather than a user specific directory. And reads from any user or root include /var/tmp/dnf databases as well as /var/cache/dnf. > >> > H. The `dnf -C` (or --cacheonly) flag does not seem to work as >> > documented. It says: > [...] >> Yep I've hit this also. > > Once this is fixed, I'm going to `alias dnf='dnf -c'` in my own user > account. Brilliant. That might just fix the whole thing. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: dnf cache downloading behavior
On Sat, Jul 22, 2017 at 05:26:55PM -0400, Neal Gompa wrote: > On Sat, Jul 22, 2017 at 5:11 PM, Zbigniew Jędrzejewski-Szmek > wrote: > > On Sat, Jul 22, 2017 at 02:06:42PM -0600, Chris Murphy wrote: > >> On Sat, Jul 22, 2017 at 1:57 PM, Matthew Miller > >> wrote: > >> > On Sat, Jul 22, 2017 at 01:42:11PM -0600, Chris Murphy wrote: > >> >> I don't know what things the unprivileged user can do other than > >> >> search and info. But off hand I'd say an unprivileged user should not > >> >> be able to download metadata. Use one /var/cache/dnf always. And if > >> >> it's stale, just inform the user. Only update the cache if the command > >> >> is issued by root. > >> > > >> > I dunno; what harm is there in giving the ability to use a separate > >> > user cache for queries? This allows you to do things like repoquery as > >> > an unprivileged user for repos that aren't enabled by default. > >> > >> I'm fine with a layered approach, *if* a repo db does not exist for > >> root, then it's OK for a user copy to be downloaded, but how about one > >> for all users to share rather than each user getting a downloaded copy > >> of the same thing? > > > > It'd probably require rearchitecturing the way that caching works. > > Current implementation does the best (maybe ignoring some minor bugs) > > of what is possible in a secure way with unprivileged users in current > > design, but we should be able to do better. Namely, create a polkit-aware > > daemon which will download metadata on demand, and then make root and > > the users forward all metadata download requests to this daemon. > > This would avoid any duplicate downloads, without the need to run > > dnf searches as root. > > > > (Ideally, dnf would also have strong tmpfiles.d policy to clean up all > > caches after ~1 month of unuse, so that if a user requests some repo, > > the disk space is not permanently wasted.) > > > > So... like dnfdaemon, except with less capabilities? Exactly! How do I use dnfdaemon? I only see the raw python and dbus APIS... Are there any plans to make dnfdaemon a primary method of interacting with dnf db? Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: dnf cache downloading behavior
On Sat, Jul 22, 2017 at 02:06:42PM -0600, Chris Murphy wrote: > > I dunno; what harm is there in giving the ability to use a separate > > user cache for queries? This allows you to do things like repoquery as > > an unprivileged user for repos that aren't enabled by default. > I'm fine with a layered approach, *if* a repo db does not exist for > root, then it's OK for a user copy to be downloaded, but how about one > for all users to share rather than each user getting a downloaded copy > of the same thing? How? Setuid downloader? Or make it world-writable? Seems sketchy. > > H. The `dnf -C` (or --cacheonly) flag does not seem to work as > > documented. It says: [...] > Yep I've hit this also. Once this is fixed, I'm going to `alias dnf='dnf -c'` in my own user account. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: dnf cache downloading behavior
On Sat, Jul 22, 2017 at 3:26 PM, Neal Gompa wrote: > On Sat, Jul 22, 2017 at 5:11 PM, Zbigniew Jędrzejewski-Szmek > wrote: >> On Sat, Jul 22, 2017 at 02:06:42PM -0600, Chris Murphy wrote: >>> On Sat, Jul 22, 2017 at 1:57 PM, Matthew Miller >>> wrote: >>> > On Sat, Jul 22, 2017 at 01:42:11PM -0600, Chris Murphy wrote: >>> >> I don't know what things the unprivileged user can do other than >>> >> search and info. But off hand I'd say an unprivileged user should not >>> >> be able to download metadata. Use one /var/cache/dnf always. And if >>> >> it's stale, just inform the user. Only update the cache if the command >>> >> is issued by root. >>> > >>> > I dunno; what harm is there in giving the ability to use a separate >>> > user cache for queries? This allows you to do things like repoquery as >>> > an unprivileged user for repos that aren't enabled by default. >>> >>> I'm fine with a layered approach, *if* a repo db does not exist for >>> root, then it's OK for a user copy to be downloaded, but how about one >>> for all users to share rather than each user getting a downloaded copy >>> of the same thing? >> >> It'd probably require rearchitecturing the way that caching works. >> Current implementation does the best (maybe ignoring some minor bugs) >> of what is possible in a secure way with unprivileged users in current >> design, but we should be able to do better. Namely, create a polkit-aware >> daemon which will download metadata on demand, and then make root and >> the users forward all metadata download requests to this daemon. >> This would avoid any duplicate downloads, without the need to run >> dnf searches as root. >> >> (Ideally, dnf would also have strong tmpfiles.d policy to clean up all >> caches after ~1 month of unuse, so that if a user requests some repo, >> the disk space is not permanently wasted.) >> > > So... like dnfdaemon, except with less capabilities? Neat. No idea if I'm alone, but I'd like Fedora Server to always have up to date repo databases (both for dnf and packagekit), and for the workstations and VM's sync with that local server. Even when I'm connected to fast internet this would be a better experience. If it were possible to have a subsettable Fedora mirror, it could exist on a continuum from metadata only, to e.g. my workstation only packages, to a full Fedora mirror. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: dnf cache downloading behavior
On Sat, Jul 22, 2017 at 5:11 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Sat, Jul 22, 2017 at 02:06:42PM -0600, Chris Murphy wrote: >> On Sat, Jul 22, 2017 at 1:57 PM, Matthew Miller >> wrote: >> > On Sat, Jul 22, 2017 at 01:42:11PM -0600, Chris Murphy wrote: >> >> I don't know what things the unprivileged user can do other than >> >> search and info. But off hand I'd say an unprivileged user should not >> >> be able to download metadata. Use one /var/cache/dnf always. And if >> >> it's stale, just inform the user. Only update the cache if the command >> >> is issued by root. >> > >> > I dunno; what harm is there in giving the ability to use a separate >> > user cache for queries? This allows you to do things like repoquery as >> > an unprivileged user for repos that aren't enabled by default. >> >> I'm fine with a layered approach, *if* a repo db does not exist for >> root, then it's OK for a user copy to be downloaded, but how about one >> for all users to share rather than each user getting a downloaded copy >> of the same thing? > > It'd probably require rearchitecturing the way that caching works. > Current implementation does the best (maybe ignoring some minor bugs) > of what is possible in a secure way with unprivileged users in current > design, but we should be able to do better. Namely, create a polkit-aware > daemon which will download metadata on demand, and then make root and > the users forward all metadata download requests to this daemon. > This would avoid any duplicate downloads, without the need to run > dnf searches as root. > > (Ideally, dnf would also have strong tmpfiles.d policy to clean up all > caches after ~1 month of unuse, so that if a user requests some repo, > the disk space is not permanently wasted.) > So... like dnfdaemon, except with less capabilities? -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: dnf cache downloading behavior
On Sat, Jul 22, 2017 at 02:06:42PM -0600, Chris Murphy wrote: > On Sat, Jul 22, 2017 at 1:57 PM, Matthew Miller > wrote: > > On Sat, Jul 22, 2017 at 01:42:11PM -0600, Chris Murphy wrote: > >> I don't know what things the unprivileged user can do other than > >> search and info. But off hand I'd say an unprivileged user should not > >> be able to download metadata. Use one /var/cache/dnf always. And if > >> it's stale, just inform the user. Only update the cache if the command > >> is issued by root. > > > > I dunno; what harm is there in giving the ability to use a separate > > user cache for queries? This allows you to do things like repoquery as > > an unprivileged user for repos that aren't enabled by default. > > I'm fine with a layered approach, *if* a repo db does not exist for > root, then it's OK for a user copy to be downloaded, but how about one > for all users to share rather than each user getting a downloaded copy > of the same thing? It'd probably require rearchitecturing the way that caching works. Current implementation does the best (maybe ignoring some minor bugs) of what is possible in a secure way with unprivileged users in current design, but we should be able to do better. Namely, create a polkit-aware daemon which will download metadata on demand, and then make root and the users forward all metadata download requests to this daemon. This would avoid any duplicate downloads, without the need to run dnf searches as root. (Ideally, dnf would also have strong tmpfiles.d policy to clean up all caches after ~1 month of unuse, so that if a user requests some repo, the disk space is not permanently wasted.) Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: dnf cache downloading behavior
On Sat, Jul 22, 2017 at 1:57 PM, Matthew Miller wrote: > On Sat, Jul 22, 2017 at 01:42:11PM -0600, Chris Murphy wrote: >> I don't know what things the unprivileged user can do other than >> search and info. But off hand I'd say an unprivileged user should not >> be able to download metadata. Use one /var/cache/dnf always. And if >> it's stale, just inform the user. Only update the cache if the command >> is issued by root. > > I dunno; what harm is there in giving the ability to use a separate > user cache for queries? This allows you to do things like repoquery as > an unprivileged user for repos that aren't enabled by default. I'm fine with a layered approach, *if* a repo db does not exist for root, then it's OK for a user copy to be downloaded, but how about one for all users to share rather than each user getting a downloaded copy of the same thing? > >> And then, dnf make cache timer is only keeping the /var/cache/dnf copy >> up to date. So the user copy is always going stale anyway. > > Yeah, that's part of the bad experience here, definitely. > > > > H. The `dnf -C` (or --cacheonly) flag does not seem to work as > documented. It says: > >-C, --cacheonly > Run entirely from system cache, don't update the cache > and use it even in case it is expired. > > DNF uses a separate cache for each user under which it > executes. The cache for the root user is called the > system cache. This switch allows a regular user read-only > access to the system cache which usually is more fresh > than the user's and thus he does not have to wait for > metadata sync. > > > but in practice: > > $ dnf clean metadata > Cache was expired > 0 files removed > $ dnf -C info > Error: Cache-only enabled but no cache for 'updates-testing' Yep I've hit this also. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: dnf cache downloading behavior
On Sat, Jul 22, 2017 at 01:42:11PM -0600, Chris Murphy wrote: > I don't know what things the unprivileged user can do other than > search and info. But off hand I'd say an unprivileged user should not > be able to download metadata. Use one /var/cache/dnf always. And if > it's stale, just inform the user. Only update the cache if the command > is issued by root. I dunno; what harm is there in giving the ability to use a separate user cache for queries? This allows you to do things like repoquery as an unprivileged user for repos that aren't enabled by default. > And then, dnf make cache timer is only keeping the /var/cache/dnf copy > up to date. So the user copy is always going stale anyway. Yeah, that's part of the bad experience here, definitely. H. The `dnf -C` (or --cacheonly) flag does not seem to work as documented. It says: -C, --cacheonly Run entirely from system cache, don't update the cache and use it even in case it is expired. DNF uses a separate cache for each user under which it executes. The cache for the root user is called the system cache. This switch allows a regular user read-only access to the system cache which usually is more fresh than the user's and thus he does not have to wait for metadata sync. but in practice: $ dnf clean metadata Cache was expired 0 files removed $ dnf -C info Error: Cache-only enabled but no cache for 'updates-testing' https://bugzilla.redhat.com/show_bug.cgi?id=1473964 -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: dnf cache downloading behavior
On Sat, Jul 22, 2017 at 1:03 PM, Matthew Miller wrote: > On Sat, Jul 22, 2017 at 11:25:48AM -0600, Chris Murphy wrote: >> > Here you aren't root so it's not using the same cache, because it can't >> > write to the root owned cache so it creates a temporary cache owned by your >> > user. >> Oh. My. God. It makes complete sense, but is also completely >> ridiculous. What a bad user experience. > > It seems like it would be completely reasonable for DNF to use the root > cache if it's considered "fresh" by the current configuration. And > actually, possibly even if it's not with a warning that the data might > be out of date, with a flag required if you really want to download the > metadata as a regular user. I don't know what things the unprivileged user can do other than search and info. But off hand I'd say an unprivileged user should not be able to download metadata. Use one /var/cache/dnf always. And if it's stale, just inform the user. Only update the cache if the command is issued by root. Multiple user machines, would each cause separately downloaded copies into /var/tmp/dnf as well? And then, dnf make cache timer is only keeping the /var/cache/dnf copy up to date. So the user copy is always going stale anyway. It's just... I don't see how this is worth it even with a fast internet connection. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: dnf cache downloading behavior
On Sat, Jul 22, 2017 at 11:25:48AM -0600, Chris Murphy wrote: > > Here you aren't root so it's not using the same cache, because it can't > > write to the root owned cache so it creates a temporary cache owned by your > > user. > Oh. My. God. It makes complete sense, but is also completely > ridiculous. What a bad user experience. It seems like it would be completely reasonable for DNF to use the root cache if it's considered "fresh" by the current configuration. And actually, possibly even if it's not with a warning that the data might be out of date, with a flag required if you really want to download the metadata as a regular user. Of course, also, this wouldn't be so bad if the required metadata download were smaller. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: dnf cache downloading behavior
On Sat, Jul 22, 2017 at 11:12 AM, Tom Hughes wrote: > On 22/07/17 17:53, Chris Murphy wrote: > >> 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 > > Here you are root. > >> 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 > > > Here you aren't root so it's not using the same cache, because it can't > write to the root owned cache so it creates a temporary cache owned by your > user. Oh. My. God. It makes complete sense, but is also completely ridiculous. What a bad user experience. > I'm not sure how dnf does it it but IIRC yum used to create the per-user > cache in /tmp so it would persist until /tmp got cleaned. > > This is why I always run dnf commands (even things like list or search) as > root so that I get the advantage of the shared cache ;-) Ughh. I hate computer security right now ... -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: dnf cache downloading behavior
Completely mindboggling... $ sudo dnf -v update [sudo] password for chris: Loaded plugins: builddep, config-manager, copr, debug, debuginfo-install, download, generate_completion_cache, needs-restarting, playground, repoclosure, repograph, repomanage, reposync DNF version: 2.5.1 cachedir: /var/cache/dnf repo: using cache for: updates-testing updates-testing: using metadata from Thu 20 Jul 2017 07:08:22 PM MDT. repo: using cache for: updates updates: using metadata from Thu 20 Jul 2017 09:22:17 AM MDT. repo: using cache for: fedora not found updateinfo for: Fedora 26 - x86_64 fedora: using metadata from Fri 07 Jul 2017 06:38:55 AM MDT. repo: using cache for: google-chrome not found deltainfo for: google-chrome not found updateinfo for: google-chrome google-chrome: using metadata from Wed 19 Jul 2017 11:37:49 AM MDT. Last metadata expiration check: 1:05:51 ago on Sat 22 Jul 2017 10:05:21 AM MDT. That's metadata that's 2-3 days stale. The current metadata from just 45 minutes ago is in /var/tmp/dnf-chris-pl3hc0v6/ It's almost like the problem is it's bouncing between /var/cache/dnf and /tmp/var/dnf* and sometimes it updates one or the other, gets confused, and it's really really... ... eyebrow raising. Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: dnf cache downloading behavior
On 22/07/17 17:53, Chris Murphy wrote: 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 Here you are root. 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 Here you aren't root so it's not using the same cache, because it can't write to the root owned cache so it creates a temporary cache owned by your user. I'm not sure how dnf does it it but IIRC yum used to create the per-user cache in /tmp so it would persist until /tmp got cleaned. This is why I always run dnf commands (even things like list or search) as root so that I get the advantage of the shared cache ;-) Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
