On Sat, Jul 22, 2017 at 1:57 PM, Matthew Miller
<mat...@fedoraproject.org> 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.
>
>
>
> Hmmmm. 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

Reply via email to