#211 Some form of caching packages to reduce redundant downloads
Closed: Invalid Opened by ghell.

It would be great if the packages did not need to be redownloaded every single time a spin is created.

For example, if a spin is created but a mistake is made, the spin may have to be recreated and everything the author just downloaded to create the first spin has to be redownloaded for the second spin even though it hasn't changed. Most packages don't change very often and testing spins often requires the author to create the spin with minor differences each time but have to redownload every package they use to do so.

There should at least be a dialogue asking you whether you want to keep the packages for spins in the near future before they are deleted.

With the current development version having a 10 second delay between downloading each package, this is even more annoying (though I expect that 10 second delay is something temporary, just for debugging, so I have not submitted this as a bug)


We should look to get with "warren" from #fedora-devel about his work with automating the setup of a squid caching server to do just this (cache yum sources). I think a nice external caching setup with an active upstream would be of value here. We could do something like revisor-cache that pulls down the config scripts for setting up squid and then also pulls down new models for revisor that have defaults to point at the local squid. Of course, these could be changed to point at some other source, but it would be nice to have an external caching mech. I look at wanting to do chroot composes. It would be great if all we had to do to make chroot composing much faster (for multiple composes at least) is have the revisor-cache plugin installed.

This is a matter of setting the expire metadata rather then having the rm -rf /var/tmp/revisor-yumcache. Please verify if this has been fixed in the latest version already, testing shows that it has.

Metadata Update from @ghell:
- Issue set to the milestone: 2.0.4 Release

Metadata