>> 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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
