Re: an idea for next generation APT archive caching

[Eduard Bloch <edi@gmx.de>]

#include <hallo.h>
* Jonathan Oxer [Thu, Oct 21 2004, 02:17:49PM]:

> > is unstable). IMHO, the only correct way is to scan the most recently
> > downloaded Packages and Source index files and delete files that
> > aren't mentioned anymore.
> 
> That's how apt-cacher does it. Early versions of apt-cacher did no cache
> cleaning and it was the #1 requested feature for a while, but once I sat
> down to actually start implementing it I discovered something that's not
> obvious until you actually try to do it yourself: Writing Cache Expiry
> Algorithms Is Bloody Hard(TM).
> 
> In the end I settled on a combination: Packages and Release files are
> expired based on age, and .debs are purged based on reference within a

And though I like apt-cacher in general (it worked immediately while I
did not manage to make apt-proxy work within 15 minutes and dropped the
crap), this is the only method I do not like at all.
It could be done better. I suggest you switch from wget to curl and use
If-Modified-Since calls to update the Package/Source/Release file only
when needed. And only when the local copy of them has changed (and the
update was clean), then the deb files should be purged (when the next
cleanup cycle comes). You could even check for index file updates based
on time periods instead of triggering it by the user. Actually, it could
be a cron-job that downloads them to /dev/null.

Further, I wish there could be pre-caching. Means: if a file was
downloaded and that file was mentioned in packages-file A and after the
next update, A has a newer version of this package than the package
could be downloaded. This would be an optional feature, of course, but
it could be implemented without millions LOC.

Regards,
Eduard.
-- 
Wer die Form zerstört, beschädigt auch den Inhalt.
		-- Herbert von Karajan