Downgrading from testing to stable

By Auke Jilderda <auke@jilderda.net> Thu Dec 26 07:22:28 2002

I couldn't find much about downgrading a distribution so I decided to write down my experiences. I followed the reference manual chapter 6 and managed to downgrade some 380 packages, leaving some 8 packages from testing that I decided not worthwhile to downgrade.

My recipe:

  1. Configure your apt-get

    Set up your /etc/apt/preferences as follows:

    Package: *
    Pin: release a=stable
    Pin-Priority: 1001

    Package: *
    Pin: release a=testing
    Pin-Priority: 60

    Package: *
    Pin: release a=unstable
    Pin-Priority: 50

    One catch though: I also had my /etc/apt/apt.conf set to:

    APT::Default-Release "stable";
    which somehow prevented downgrading. Removing it for the time being fixed it but I don't quite get why. I'd expect it to not matter with the preferences file set as above.

  2. Run "apt-get upgrade"

    It'll fetch all packages it needs and start downgrading. It will fail on a number of occassions, each of which I fixed before re-running "apt-get upgrade" to continue. In hindsight, "apt-get dist-upgrade" seems more suitable for the job but I hadn't thought of that.

    1. On my system, it failed to downgrade the dpkg itself so I forced it:
      dpkg --force-depends -r dselect
      dpkg -i /var/cache/apt/archives/dpkg_1.9.21_i386.deb
      It would probably have been better to pin the version from testing (similar to the package below) but ok.
    2. It failed to downgrade fileutils, shellutils, and textutils because of the package coreutils. Again, I forced dpkg to overwrite:
      dpkg -i --force-overwrite /var/cache/apt/archives/fileutils_4.1-10_i386.deb
      dpkg -i --force-overwrite /var/cache/apt/archives/shellutils_2.0.11-11_i386.deb
      dpkg -i --force-overwrite /var/cache/apt/archives/textutils_2.0-12_i386.deb
      After that, the rest went fairly smooth (though I had to restart "apt-get upgrade" a couple of times before it finished).

  3. Next, I checked which package was in which distribution:
    apt-show-versions | fgrep /stable
    apt-show-versions | fgrep /testing
    apt-show-versions | fgrep /unstable
    There turned out to be a couple of packages left. I removed the ones I don't use anyway, downgraded a couple by hand, and decided to leave the remaining 8 untouched, partly because they're too risky to screw up (e.g. libc6) and partly because it turned out I'm using functionality of the newer versions (e.g. e2fsprogs, gnupg):
    debian-reference-en/testing uptodate 1.05-2
    debian-reference-common/testing uptodate 1.05-2
    e2fsprogs/testing uptodate 1.29+1.30-WIP-0930-1
    gnupg/testing uptodate 1.2.0-1
    libc6-dev/testing uptodate 2.2.5-14.3
    libc6/testing uptodate 2.2.5-14.3
    locales/testing uptodate 2.2.5-14.3
    libdb1-compat/testing uptodate 2.1.3-7
  4. I pinned the two packages of which I keep the testing version by adding the following to /etc/apt/preferences:
    Package: e2fsprogs
    Pin: version 1.29*
    Pin-Priority: 1002

    Package: gnupg
    Pin: version 1.2.0*
    Pin-Priority: 1002
    Am not entirely sure whether this is ok but it works for now. My reason for pinning verions rather than distributions is that I'd like it to automagically move onto stable in time: when the version arrives in stable, I'd like to keep that instead of upgrade to the next testing version. However, it seems pinning versions can get out of sync so I'll have to dig into those pin priorities some time soon.

Summarising, downgrading is complex and cumbersome but it can be done and doesn't break my system. Hence, Debian package management can get less than trivial but most definately rules! :-)

By Osamu Aoki < osamu@debian.org > Thu Dec 26 07:22:28 2002

I would have pinned the all these packages which was needed to be from testing version by adding the following to /etc/apt/preferences for each packages:

Package: e2fsprogs
Pin: release a=testing
Pin-Priority: 1002
...