Bug#160743: I want a very different autoclean feature
>> I thought about that, but it's sometimes not the right thing; I've
>> seen problems with a major new upstream release lead to a flurry of
>> .deb releases, but I end up needing to revert to the old version.
>> (I seem to remember this happening with samba a while ago.)
> So you update, it fails, you downgrade to the previously installed
> version.
>
> Previously installed, not just previous version. It should keep the
> installed and the last working version in cache.
But sometimes, I upgrade, it fails, I try a few proposed fixes, they don't
work either, *then* I roll back. 2.0-1 didn't work right, so there's
a quick run through 2.0-2, 2.0-3 and 2.0-4 before I decide to go back to
version 1.6.
Or it may take me a while to notice a problem. I once had a CUPS
problem where one particular app couldn't print, and that took a
while to find. If there had been a second release in that time,
I would have lost my "known good" backup.
Major version upgrades cause lots of problems which cause lots of
releases. Consider Samba 2:3.2.0-4, released 26 hours after
2:3.2.0-3 (the first non-experimental release of 3.2.0) broke
user passwords.
Or Samba 3.0.6-2, which came along 5 hours after 3.0.6-1. I don't
remember if I had any problems with 3.0.6, but both suffered from "grave"
bug #267704 (fixed in -3 two days later).
The other question this solution raises is when do you delete the .deb
file for a deleted (no longer installed) package? Never? Obviously, if
it was uninstalled to make room for a conflicting new package, I might
need it to recover a working state.
> All just a workaround but maybe it helps you over the time till someone
> implements a configurable policy framework for apt-get (auto)clean.
Thanks for the useful workaround ideas.
Reply to: