<p dir="ltr">For now we're just using the squid unmount partition and wipe strategy. :-P</p>
<div class="gmail_quote">On Jul 13, 2016 10:46 PM, "Eduard Bloch" <<a href="mailto:edi@gmx.de">edi@gmx.de</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hallo,<br>
* Octavian Hornoiu [Wed, Jul 13 2016, 01:54:03PM]:<br>
>    Is there a way to limit the cache size due to space constraints?<br>
>    Is there a way to evict packages from the cache to reduce the total cache<br>
>    size below a certain limit?<br>
>    Thanks!<br>
>    Octavian<br>
<br>
At the moment, no. But I am well aware of this trouble since and there<br>
are some ideas on how to design a cleanup strategy.<br>
<br>
We hit the classic problem here - how to decide which packages to keep<br>
and which to throw away?<br>
<br>
ATM I tend to create some kind of "importance rating" which would be<br>
calculated from the number of downloads of a certain file and the age of<br>
that downloads and the file size. The factors in this formula would be<br>
customizable. In addition, there could be a classic bin-packing problem<br>
solver that estimates how to remove bigger files to preserve smaller<br>
files. So, by the end, a bit latex font package might be removed if only<br>
used by one person in order to keep a dozen of smaller packages that are<br>
likely to be used by multiple people.<br>
<br>
But eventually all this might be just reading tea leaves. Especially<br>
when a popular package has been renamed, the algorithm needs to identify<br>
the predecessor and migrate the rating accordingly.<br>
<br>
Regards,<br>
Eduard.<br>
</blockquote></div>