yum clean bug

Jeff Spaleta jspaleta at gmail.com
Fri Dec 9 20:30:09 UTC 2005


On 12/9/05, Nicolas Mailhot <nicolas.mailhot at laposte.net> 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




More information about the fedora-devel-list mailing list