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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
