On 12/9/05, Nicolas Mailhot <nicolas.mailhot@xxxxxxxxxxx> 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 ? (this would correspond to standard home-keeping after repo > removal/renaming). Shrug... or is this the job of the mechanism that removes or renames? Other tools routinely remove this kind of leftovers > or at least flag them specific examples of tools that do this? > 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"¹) ? Even Mozilla/Firefox/etc allow this, and they > have to manage users that would never approach the command line let > alone yum if yum were a gui application... i could see an argument for exposing better UI for sanitize functions. But since yum isn't a gui... there isn't a lot of choices on how to expose "easier" ui. Cmdline tools expose options via cmdline switches. Mozilla has ui exposed to remove the .mozilla directory completely? > Remember, this is yum's private repository, only yum writes in it only yum writes to it? Can you be "sure" of that? I didn't realize that the FHS mandated that a single application writes to its associated /var/cache/ subdirectory and that all other applications leave that directory alone. In fact I've think you have argued the opposite already. Just because yum could nuke the whole tree on every operation.. does not mean that is the best way to use the cache resources which have already been generated. Just because there is data in the directory tree that yum doesn't map to a configured repository doesn't mean its not cache that is useful for some other tool. -jef"<breaks into song> We are the users We are the local admins We are the ones with i/o and cpu constrains So let's start caching It's a choice we're making we're saving our old cache its true it makes a less i/o and cpu intensive day for you and me... </end pardon>"spaleta -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
