severity 407511 grave thanks This really is a terrible bug, and I'm appalled that it has still not been fixed yet. Upgrades from oldstable to testing or unstable, or from a previous oldstable to current stable, are not tested and are extremely risky. Is it critical that the user can rely on APT to honour the Default-Release, in order that dist-upgrade does the right thing. APT must treat an unrecognised or unmatched value as a configuration error. For example, today I attempted an upgrade from lenny to squeeze on a system which also has sid in sources. I set APT::Default-Release to "squeeze", but the version of APT in lenny didn't support codenames here. When I realised that I was getting some post-squeeze packages installed, I interrupted the upgrade, only to find that apt was broken - apparently due to version skew between the various libc6 packages. (This might be a bug in libc6, but versioned dependencies are not required if the minimum version is satisfied by the previous stable release.) I eventually had to resort to using ar and tar to unpack one package, because dpkg became broken too. Obviously this example will not be repeated in future upgrades between stable releases because codenames are supported, but there is still the possibility of someone setting Default-Release to a version or codename for which there are no sources configured, or simply making a typo in the value. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse.
Attachment:
signature.asc
Description: This is a digitally signed message part