Re: rolling-back, reverting system upgrades?
On Mon, Dec 21, 2009 at 06:42:46AM -0800, Andrew Sackville-West wrote:
> On Mon, Dec 21, 2009 at 10:43:53AM +0000, Liviu Andronic wrote:
> > Dear all
> > How would I roll back system upgrades?
> This is the purpose of the testing distribution, to test packages for
> breakage so that bugs don't migrate into stable with the next
> release. With all due respect, if you aren't prepared to deal with
> occaisional breakage, then you should be running testing.
>
> > In the old times with Gentoo, breakages occurred more often than
> > needed, but it was quite easy to revert an upgrade: each
> > tree---stable and testing---usually contained several, similar
> > versions of the package (much closer than in Lenny and
> > Squeeze). That meant that whenever something went wrong after a
> > package upgrade, I simply reverted to a previous minor version, got
> > on with my work and waited for a new version to pop up.
>
> as I said above, you can often manually fix things using dpkg and the
> old debs. Sometimes you'd have to force it. But to really make this
> work, you have to keep careful tabs on what packages were upgraded and
> cause the breakage. So far as I know there is no automated way of
> doing this.
>
Two of the machines I use regularly dual-boot into testing. I use one to
examine the new packages. The other I leave alone until it seems safe.
I like to think I *qualified* myself for testing by learning to use aptitude.
In lenny, I had to pin lots of backports packages. (Luckily I didn't get into
some system wide pinning scheme.)
With aptitude preferences set correctly, I never have to worry about a
package being upgraded until I select it and I can always put a
package on hold if it concerns me.
My rules for running testing with aptitude:
1. Don't treat testing as a "rolling release." Get used to ignoring a
sometimes inflated pool of upgradable packages.
2. Consult aptitude's dependency handling and play with it, you might
noticing things to help undo log jams.
3. Only upgrade packages that you are comfortable with or well read on, as
the case may require. Maybe start here:
http://packages.qa.debian.org/common/index.html.
4. Install apt-listbugs.
5. Put packages you are unsure of on hold in aptitude.
6. Set aptitude preferences to display changes in advance and read first.
7. Set aptitude preferences not to delete obsolete packages and don't clean
the cache to often.
7.a. However, this may not help with upgrades because the prior version will
still be replaced I think.
8. Do the above on a schedule so it doesn't get rushed.
I have started to look into apt-cacher to see if that can pool older
versions, given the disk space. Currently, my brain doesn't have much info
absorption capacity left for that.
The other thing, given disk space, might be to dual-boot two installations
of testing, one to test testing. "sup dog, I heard you like testing so I
installed a version of testing with your testing so you can test testing
while your run testing." Maybe too much work. :)
--
Freeman
Reply to: