Downgrading to an earlier Debian branch

The best (albeit hyper-condensed) answer is given in the #debian IRC channel FAQ at http://www.linuks.mine.nu/debian-faq/:

Q: Can I downgrade, like unstable->testing, testing->stable or unstable->stable?

A: It's not possible with apt-get at the moment and probably never will be supported because why would you want to downgrade in the first place?
Addendum from Thomas.Blatter@wanadoo.fr: This is not true, with pinning one can easily downgrade (I successfully did it once, from unstable to stable). One uses negative pin-numbers to uninstall/downgrade (cf. man sources.list and google "apt-get pinning").

Discussion from the debian-devel mailing list and the Debian Planet Web site follows:

From: Rudolf Lohner
Subject: Re: How to downgrade to stable?
Date: Mon, 14 Jul 2003 12:27:57 -0700
```
On Samstag, 12. Juli 2003 19:05, A.L.Meyers wrote:
> Hi!  The thread on the subject was not conclusive.
>
> Have
  [...]
> in /etc/apt/preferences.
>
> Should
>
> apt-get -t stable upgrade
>
>
> do the job?
>
> Lucien
```
Hi Lucien,

Recently I downgraded two mixed Debian stable/testing systems:

I first tried it in a sandbox (vmware) to collect some experience with it. After some failures I finally succeeded and took notes about the steps which I think were most relevant. These notes follow at the end.

Then I did the same with a real system, which succeeded on the first try :-)

On both systems even libc6 was successfully downgraded from version 2.3.1 to version 2.2.5.

I used the information from the previous thread plus extensive Google'ing.

Of course systems differ a lot from each other. So you might experience other problems - I can't guarantee for anything!

If you have the chance, try it in a sandbox first!

As I said it worked for me.

Good luck, Rudolf

Downgrading Debian testing to woody

I actually first installed woody, then upgraded it to testing (via apt-get dist-upgrade) and then applied the following steps to downgrade it to woody again.

See also second contribution in http://www.debianplanet.org/node.php?id=880 as well as http://lists.debian.org/debian-user/2003/debian-user-200304/msg02477.html Section 3.10 in http://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html and possibly others.
```
Search Google for: 'debian downgrading coreutils'
              for: 'debian downgrading packages'
          and for: 'apt pinning'

Create /etc/apt/preferences with the contents:

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

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

        Package: *
        Pin: release a=unstable
        Pin-Priority: 50
```
With /etc/apt/sources.list pointing to a stable and a testing distribution do:
```
apt-get update
apt-get -s upgrade    (just to check what would happen)
apt-get  upgrade
```
Most likely errors will occur like:

dpkg: error processing /var/cache/apt/archives/debianutils_1.16_i386.deb (--unpack): trying to overwrite `/bin/readlink', which is also in package coreutils

In this case the woody packages which contain the conflicting file should be installed with '--force-overwrite'. After this 'apt-get upgrade' will run further up to the next conflict. If in doubt about which packages to install manually consult Debians packages search page: http://www.debian.org/distrib/packages

Sometimes packages (in testing) depend on packages which do not exist in woody. This may be resolved by just removing the dependency packages. For example libpaperg_1.1.13 (testing) depends on libpaper1 and also libpaper-utils is in the way (both in testing): removing both by hand (--force-depends) allows libpaperg to be downgraded.

NOTE: coreutils is in testing only! To remove it four packages from woody must be installed first by hand: fileutils, shellutils, textutils and debianutils.

So continue the adventure similar to this:
```
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
dpkg -i --force-overwrite /var/cache/apt/archives/debianutils_1.16_i386.deb 
apt-get  upgrade
dpkg --force-depends -r dselect
dpkg -i /var/cache/apt/archives/dpkg_1.9.21_i386.deb
apt-get  upgrade
dpkg -i --force-overwrite /var/cache/apt/archives/sysvinit_2.84-2woody1_i386.deb 
dpkg  --force-depends -r libpaper1 libpaper-utils
apt-get -f  upgrade
dpkg -r tktable-dev
apt-get  upgrade
```
After installation of all packages 'apt-get upgrade' might still have problems configuring these packages because of dependency problems. It may help to remove one of the dependency packages explicitly and then reinstall it again (together with further dependency packages if needed), as with libgnomeprint-bin which could not be configured since it depended on the yet unconfigured package libgnomeprint-data:
```
dpkg --force-depends -r libgnomeprint-data
apt-get  install libgnomeprint-bin libgnomeprint-data
```
Now this did set up and configure both libgnomeprint-bin as well as libgnomeprint-data and all the remaining packages :-))))

However: Still libc6 Version 2.3.1 was installed (from testing)!

To downgrade libc6 to Version 2.2.5 (woody) force it with:
```
apt-get install libc6/stable
```
This will again remove and downgrade a lot of things, in particular now package coreutils will be removed which should not be problem since the woody equivalents (fileutils, shellutils, textutils and debianutils) are installed already. Nevertheless, if no important packages are to be removed (without being reinstalled or downgraded or being obsolete in woody, always check apt-get first with option -s) then affirm the execution of this command with 'Yes, do as I say!' as required by apt-get.

A few packages from testing still remained. Another
```
apt-get upgrade
```
...reduced their number by another five. Just 14 packages from testing remained which seem to be not very essential:
```
dictionaries-common/testing     uptodate  0.9.51
gcc-3.3-base/testing            uptodate  1:3.3-2
gnome-desktop-data/testing      uptodate  2.2.2-1
initscripts/testing             uptodate  2.85-4.1
libgnomecanvas2-common/testing  uptodate  2.2.1-1
libgnomeui-common/testing       uptodate  2.2.0.1-2
libwnck-common/testing          uptodate  2.2.2-1
python2.2-extclass/testing      uptodate  1.2.0zope-2.5.1-1.2
python2.2-gadfly/testing        uptodate  1.0.0-3
python2.2-htmlgen/testing       uptodate  2.2.2-9
sysv-rc/testing                 uptodate  2.85-4.1
wenglish/testing                uptodate  2.0-2.4
wngerman/testing                uptodate  20030222-1
xprt-common/testing             uptodate  0.0.8.cvs20030508-1
```
The rest of the system is now in woody again as confirmed by
```
apt-show-version
```
Finally, it seems to be a good idea to restart demons that depend on libc6 or just to reboot the machine (if possible) in order to make the demons depend on the new (old) libraries.
--
Rudolf Lohner --- Universitaet Karlsruhe (TH) --- Rechenzentrum
Zirkel 2, D-76128 Karlsruhe, phone/fax: +49 721 {608-6958 | 32550}
www: http://www.uni-karlsruhe.de/~Rudolf.Lohner

Subject: pinning
Author: dopey
Date: Tuesday, 2002/12/10 - 00:47

It would have been easier, I'd have thought, to use the "pinning" feature.
```
Package: *
Pin: release a=stable
Pin-Priority: 2000
```
then run "apt-get upgrade".

Subject: Strands at dpkg...
Author: KjetilK
Date: Wednesday, 2002/12/11 - 15:58

I've asked on various mailing lists about this, since I accidentally let my main server track testing a couple of weeks after Woody was released.

I pretty much tried the method you suggested, but ran into problems, and when I asked the response was pretty much: "Downgrades are not supported".

Right now, I'm just getting:

0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

...if I go apt-get -u dist-upgrade (as per the APT HOWTO), but back then, the downgrade stranded on trying to downgrade dpkg. Apparently, it couldn't downgrade dpkg, because dpkg was in use, obviously.

Is there a way around this? Perhaps I have to use force? I'm, a peaceful man, and I don't like the use of force, so if there is a kinder, gentler way, I would love to hear about it.

Subject: Downgrading dpkg
Author: hjhornbeck
Date: Thursday, 2002/12/19 - 23:16

I never had to downgrade dpkg, thankfully, but there may be a way around that:

1. Back up /var/lib/dpkg, and have a .deb of your current version of dpkg, in case this doesn't work.

2. Find a Debian-based bootdisk with dpkg on it, and boot from it.

3. Mount your root filesystem on /mnt/target, or any other convenient directory. If you put /usr, /var, /etc, or /sbin onto other partitions, mount them in their proper places under that directory.

4. Try: dpkg --root=/mnt/target -i [older dpkg .deb] That should overwrite the newer dpkg's files with the older.

I haven't tested it, so I can't confirm it works. Some other command line options to try are "--instdir=" and "--admindir="; more info can be found in dpkg's man page.

HJ Hornbeck

Subject: APT pinning and how to fix gliches of the results
Author: osamu
Date: Tuesday, 2003/02/18 - 05:09

Here are one of the "Debian Reference" reader's comment on the downgrading experience, followed by my comments for that. Anyway, as few other posts already pointed out, APT pinning is the way to downgrade system.

Subject: 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.

2a. 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.

2b. 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! :-)

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

First, my word of warning. I saw many people encounter trouble by setting "APT::Default-Release" in /etc/apt/apt.conf or setting "-t stable" on the command line of apt-get command. These set Pin-Priority to 990 overriding values in /etc/apt/preferences. So do not do this for downgrade.

I see Auke's effort and its result to be very good. Analysis of the packages which did not get downgraded are:
- These packages are only available in testing and cannot be downgraded:
  debian-reference-en/testing uptodate 1.05-2
  debian-reference-common/testing uptodate 1.05-2
- These packages are availabe in testing and needed to access recent enhancements. (This is a choice made by Auke.)
  e2fsprogs/testing uptodate 1.29+1.30-WIP-0930-1
  gnupg/testing uptodate 1.2.0-1
- These packages are required to satisfy above packages ("Depends:" entry in control file).
  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
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
...

This should enable me to continuously in-sync with testing for these programs. If you do not need update, just do not run "update". But at the same time, keeping mixed system tends to pull libc6 update etc. into system. Sometimes, it is not desired. So think about recompile those packages if possible.

In my previous experiences, libc6 and its friends always needed to be updated if any newer packages needed to be installed to the system. Also, Perl and Bash needed to be newer to support some newer packages in stable/testing mixed environment during the days of potato/woody. Sometimes newer kernel requires new gcc and its friends too.

FYI: I have been conservative on upgrading daemon programs while aggressive on end-user gui application. Also security issues using testing or unstable needs to be reminded for the folks who use those programs in testing and unstable.

Happy life with Debian.

Downgrading to an earlier Debian branch

Downgrading Debian testing to woody