> --cacheonly
> With this option yum will work within it's cache directories only, so
> if it needs to download some extra data from the network it will fail.
> I meant if someone leaves cachedir == system cache and sets cache=1.
> I know there were a lot of small scripts that did that (before we had
> setCacheDir()).
I see.. We'd fail with OSError on mkdir() instead of raising RepoError.
Would have to handle this when skip_if_unavailable=1, too.
> > a) revert 0f03409
>
> Doing this means that users are at the whims of root, if the system
> cache dir. isn't upto date with all the data they need available they
> are screwed (as they don't have permission to fix anything).
Users can always drop -C and have a writable cachedir, can't they?
> > b) system=>user preloading with --cacheonly.
>
> Right, that was on the plan and in your patches.
> The only real downside here is that we need multiple copies of
> things ... but AFAICS having per. user caches is the only way to get
> it completely fixed.
Just stumbled on this:
def doLock(...):
if self.conf.uid != 0:
# If we are a user, assume we are using the root cache ... so don't
# bother locking.
if self.conf.cache:
return
This not longer holds, and we preload/mkdir without locking..
That may be bad, but waiting for a lock in completion-helper
isn't great either.. (though it's the user lock only).
> cachedir=system
>
> 1. Must use -C and make the repos. readonly, because we don't have
> permission to download or alter them anyway.
>
> 2. Due to #1 if the cache isn't usable, we are just screwed.
The -C option is not mandatory. If you are sure root's cache
is updated timely, use it. Otherwise.. don't.
_______________________________________________
Yum-devel mailing list
Yum-devel@lists.baseurl.org
http://lists.baseurl.org/mailman/listinfo/yum-devel
