I discovered this when trying to install aspell from unstable.

How to reproduce:
# apt-get install aspell
The following extra packages will be installed:
   aspell-bin aspell-en libaspell15
The following NEW packages will be installed:
   aspell aspell-bin aspell-en libaspell15
(Fine so far, but why list the packages twice?)
[deleted lots of "unpacking..."]

This installed fine. But I want the norwegian dictionary:
# apt-get install aspell-no
Reading Package Lists... Done
Building Dependency Tree... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.

Since you only requested a single operation it is extremely likely that
the package is simply not installable and a bug report against
that package should be filed.
The following information may help to resolve the situation:

Sorry, but the following packages have unmet dependencies:
   aspell-no: Depends: aspell but it is not going to be installed
E: Sorry, broken packages

Yes, the package is not installable.  But the rest of the
message is wrong.  It tells me that aspell isn't going to be
installed, but as you see above, it _is_ installed.  So that
cannot be the true problem.  Lets try to be explicit, and specify
the existing package also:

#apt-get install aspell-no aspell
Reading Package Lists... Done
Building Dependency Tree... Done
Sorry, aspell is already the newest version.
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

Sorry, but the following packages have unmet dependencies:
   libaspell15: Conflicts: aspell-no (<= 2.0-9) but 2.0-9 is to be installed
E: Sorry, broken packages

Ok, so the dictionary is outdated and can't work with the new libaspell15,
(which is required for aspell to work.)  Why didn't I get this message
when i did the "apt-get install aspell-no" without specifying the
installed aspell package?

This would be even better:
"Conflict: aspell-no version <=2.0-9 conflicts with libaspell15, and
aspell-no
depends upon libaspell15 indirectly.  It is therefore uninstallable."
Printing the dependency chain might be better, in case there are
alternatives
to the in-between programs (in this case the aspell package)
Unless this leads to lots of very long chains being printed.

Helge Hafting

Hello submitters.

Zygo, your first proposal makes sense and would be good to implement.
Helge, your proposal matches above one.

Zygo, your 2nd and 3rd proposals are 'wontfix', because Debian doesn't support downgrading
officially, therefore apt cannot have 'downgrade' or 'dist-downgrade' option.
Remove/purge+install cannot resolve dependencies better than just upgrading.

Seven years ago, when this bug was filed, remove/purge+install did quite
often resolve dependencies better than just upgrading.  Apt's dependency
resolver at the time was quite limited (or maybe a better word is
"broken") and often was "blinded" by a single conflicting package.
Removing that package allowed apt-get to consider other upgrade plans,
and often those plans included installing the exactly the same package
that was just removed.

Since then the apt tools have improved considerably.  I generally do
dist-upgrades now by first upgrading apt and aptitude, then upgrading
the rest of the system, because each Debian release's aptitude package
has a much better dependency resolver than the previous one.

I generally use aptitude more than apt-get now, although there are still
differences between the two that are useful when one or the other cannot
resolve dependencies in specific situations.

Aptitude's interactive dependency resolver and apt preferences do a
fairly good job at implementing all three proposals, including downgrades.
Although I haven't attempted a full dist-downgrade in years, I have done
downgrades of families of hundreds of packagse (e.g. dependents of perl
and libglib) from Lenny to Etch with aptitude, apt preferences, and a
bit of manual hinting in the dependency resolver.