> To put in my 2c I would forgo the time limit. > > Keep every available, installed and the previously installed version.
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.) Even if it's pilot error and I just haven't forward-ported the local configuration properly to the new config file syntax, I can still need to revert to get it working NOW, damn it. On the other hand, I probably don't need the before-previous release of an infrequently-released package. (E.g. filters 2.46, which I installed October '08.) > This can be hacked together with a Dpkg::Post-Invoke method that creates > a Packages file listing the respective versions and "deb file:///path > ./" in sources.list. But it's certainly not a clean solution. Thanks for the hint; I might try something like that. I can keep a series of such files and roll them over in cron.weekly or some such. But while that will make "apt-get autoclean" do the right thing, it's still very easy to accidentally invoke "apt-get clean" via various front-ends. Especially if you bounce back and forth between machines with different package retention policies. It would still be nice to have a built-in feature to disable that. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
