Jeff Spaleta wrote:
On 12/9/05, Nicolas Mailhot <nicolas.mailhot(a)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?
OO.o will remove crash dumps after restart
amanda will list any file in its backup queue it does not expect (either
previous runs leftovers or files someone else dumped there)
> 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?
Mozilla has ui exposed to remove its cache completely.
No one is talking about removing /etc/yum.* completely (which would
correspond to your .mozilla example)
> 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.
Nah, I've argued other apps could remove its contents not that they
could write there. Read the spec again, nowhere is writing mentioned
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.
Who asked for nuking the whole tree on every operation ?
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.
Which tool ? With what justification ?
Since I've been asked to justify every assertion I used, could you
consider stopping the handwaving please ?
--
Nicolas Mailhot