On Thu, 13 Sep 2001, Matt Zimmerman wrote: > On Mon, Sep 10, 2001 at 04:49:02PM -0600, Jason Gunthorpe wrote: > > > A better solution to your problem is a preditictive usage sensative > > debian-specific cache. It could download off peak hours, at a > > slower+kinder rate and have the new .debs prepared before the client > > requests them. > > > > Nobody has written such a cache (apt-proxy doesn't quite do it all), but I > > think it would be incredibly handy for large orginizations such as yours. > > What additional features would be needed in such a cache? > > - Fine-tuning cache parameters for .deb's, Packages files, etc. > (I finally seem to have convinced Squid to do this correctly)
It wouldn't be a cache so much as an active partial mirror, who's content is driven by client requests. So if I fetch foo.deb one day, the 'cache' would fetch all future versions of foo.deb and all its' dependencies recursively in anticipation that I would eventually upgrade foo.deb Some people might want some code to make the cache bounded in size though. > - Priming the cache before running upgrades (wget --delete-after) That only works for 1 workstation. You really need to aggregate package selections for all workstations and manage the cache that way. Jason
