[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: