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