yum clean bug

[Jesse Keating]

On Fri, 2005-12-09 at 21:10 +0100, Nicolas Mailhot wrote:
> 1. shouldn't yum remove every part of /var/cache/yum not covered by a
> repo (enabled or not) since obviously it can not use it for optimization
> purposes ?

No.  Just because the current run of yum isn't using it doesn't mean
that the next run of yum would.  Again it is guessing as to why the repo
isn't there anymore, something that Seth has indicated that he does not
want to delete on.  Err on the side of data protection.  This is a very
simple standard, should be easy to understand.

>  (this would correspond to standard home-keeping after repo
> removal/renaming). Other tools routinely remove this kind of leftovers
> or at least flag them (yum leftovers can be huge, a repo can consume
> hundreds of MiBs in old downloaded packages, and people seem to like
> renaming repositories). Unless there is some other reason to keep it ?
> (but then it does not belong in /var/cache/yum anymore)

Yum doesn't know for sure what the user wants to do with this.  Rather
than delete it out from under the user, we let the user decide when to
clean it out, with an rm -f.  You seem to be stuck a bit upon the idea
of /var/cache.  Just because the data _can_ be deleted doesn't mean it
_should_ be deleted.  Or just because the user may want to keep it
around for a bit doesn't mean that it automatically has to be moved out
of /var/cache.  Cache timeouts, verifications, etc.. these are actions
that other applications use to determine when/if to dump the cache.  If
an application decides that it would like the cache to stick around,
does that mean it has to go into /var/spool?  No.  Please understand
that just because the user may wish the cache to stick around doesn't
mean that it has to move out of /var/cache.

> 2. couldn't the user be allowed to easily purge the cache (and no
> enablerepo=* does not count as easily, especially considering Seth finds
> rpm flags "cryptic"¹) ? 

rm -rf /var/cache/yum/*  That does a clean all all.  (clean all the
cache components from all the repositories ever known to yum).


> Even Mozilla/Firefox/etc allow this, and they
> have to manage users that would never approach the command line let
> alone yum

You're comparing a graphical application to yum for ease of use?  Come
on...  Go make this suggestion to whatever gui yum frontend you like.
They can do an rm -rf of the cache dir if they want.  Yum will recreate
it.  The users can complain if this frontend does things they don't
like.

> Remember, this is yum's private repository, only yum writes in it (the
> FHS allows nuking the cache of someone else not messing in any other way
> with it), and the data inside can be re-generated when needed (your words)

Just because it is allowed does not mean it is a good practice.  Unless
there is really really really good reasons, applications don't futz w/
the caches of other applications.  Especially because nuking cache WHILE
the application is using it can lead to unexpected difficulties.  Now a
utility or a front end can nuke the cache for yum, however it then
becomes the responsibility of that utility or front end to make the
assumptions on the user's behalf.  Yum itself will always err on the
side of data protection.  Don't remove it unless explicitly told to w/
enable repo, or if the admin removes it by hand.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating