[Yum-devel] [PATCH] preload_from_sys also with --cacheonly, BZ 830523

[James Antill]

On Fri, 2012-06-15 at 07:46 -0400, Zdenek Pavlas wrote:
> > --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.

 Right, and we have problems turning that into a usable error message.
Hence the pre-emptive raises.

> > > 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?

 In theory, yes. But users tend to see it more from the POV of
"*&^(&* you make -C work" ... :)

 Also there are things like bash completion which use -C "behind the
scenes" with no simple alternative.

> > > 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).

 Yeh, it's a holdover from when -C as user meant they were always using
root's cache ... and we can't just delete those lines, as we still can't
lock if cachedir==system and we're the user.
 I guess we have to test .conf.cachedir or, look at if we are the user
if getting the lock fails.

> >  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.

 There are times you can try that argument, and win. IMO we've passed
that point ... a long time ago we had:

user: yum    => always used root's cache in r/o mode.
user: yum -C => always used root's cache in r/o mode.

...but that annoyed people because unless root updated the cache
regularly you couldn't do anything. Even though things like repoquery
--repofrompath had to be run as root, this is the point where we maybe
could have said "don't do that then". But we had to go and fix it, so
people didn't have to run stuff as root and then we had:

user: yum    => used .setCacheDir().
user: yum -C => always used root's cache in r/o mode.

...now repoquery/yum/etc. mostly works fine, and yum -C "often" works
the same (but without some network checks etc.) ... but it fails in
weird ways if you do "yum makecache" => "yum -C blah" (what completion
does), and there are edge cases like wanting to use -C but also enable a
random repo. which can't work easily.
 And gave us all the joy of "run: yum foo ... download everything" and
then "run: sudo yum bar ... and download everything again"
 Saying "don't do that" at this point is much harder to argue, because
all the failures are edge cases and look much more like bugs than
missing features.