Comment 5 for bug 24626

This is an old, known, upstream issue. The reason for the limit is to prevent the cache from getting so large that it crowds out more important files on whatever partition /var is on. The Debian developers tend to be very conservative and figure that it's better to have a low limit and protect low resource systems than have a high limit and end up with an unbootable system. There have been several discussions about removing the limit, but the conventional wisdom still seems to be to keep it.

Personally, I think that a 12 MB limit is ludicrously low, even for low-resource systems. (It would be better to put limits on log files than on the apt cache.) When I run into the issue, I raise the limit to a rather large number, like 120MB. Granted, it's unlikely that the cache should ever get that big, but that's the point: the limit should prevent a runaway cache size but not ever get in the way of anything useful.

A better, more permanent way to fix the issue is to create a cache file in /etc/apt/apt.conf.d/, like this:
# echo 'APT::Cache-Limit "125829120" ' > /etc/apt/apt.conf.d/30cache

The only issue for releasing this as a patch is to ensure that the update doesn't cause problems for corner cases where the sysadmin knew about and relied on the cache limit. A possible solution is to have the upgrade script calculate a limit programmatically to the lower of:
(1) an arbitrary percentage (say, 5%) of the total disk space on the partition where /var resides;
(2) an arbitrary percentage (say 25%) of the total free disk space on the partition where /var resides; and
(3) an arbitrary, but high, absolute limit (say, 125829120).

Using the example limits I have listed, the limit would be set lower on machines where the /var directory is on a partition of less than 2 GB or where the free space remaining on that partition is less than approximately 500 MB.

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.biz