[Aptitude-devel] Bug#643997: aptitude: user-requested downgrade should not cause (so much of a) downgrade penalty for conflict resolution

[ydirson at free.fr]

> 2011-10-01 15:59 Yann Dirson:
> >Package: aptitude
> >Version: 0.6.3-4
> >Severity: normal
> >
> >The "downgrade" use-case surely needs some love those days thanks to
> >the moz foundation: I rapidly had a test of iceweasel 7 in unstable
> >(eager to get better ram usage ;), just to conclude that so many
> >extensions are not compatible.
> >
> >So let's try to get back to v6... iceweasel-dbg has a scrict dep,
> >what
> >are the first suggestions from aptitude ?  Each of them summarized
> >below, one per paragraph.
> >
> >I originally thought it was just a problem of "downgrade" being
> >rated
> >too bad - and incidentally, when asked to explicitely downgrade,
> >aptitude should surely not inflict a downgrade-penalty to packages
> >that are broken by the downgrade.  But even then, how to explain
> >that
> >version from squeeze is elected first, then version from
> >moz.d.n/wheezy, and that just downgrading -dbg to wheezy itself is
> >not
> >even ever considerered, whereas the priority of those packages is
> >highest ?
> 
> From apt_preferences man page:
> 
>        APT then applies the following rules, listed in order of
>        precedence, to determine which version of a package to
>        install.
> 
>        · Never downgrade unless the priority of an available version
>          exceeds 1000. ("Downgrading" is installing a less recent
>          version of a package in place of a more recent version. Note
>          that none of APT's default priorities exceeds 1000; such
>          high
>          priorities can only be set in the preferences file. Note
>          also
>          that downgrading a package can be risky.)
> 
> So even if pin priority is higher, since none of them is higher than
> 1000, it's not supposed to facilitate downgrades in any way.
> 
> 
> More in general, downgrades are not supported, so I don't think that
> it
> should be a goal of aptitude or any other tool making this action
> very
> easy / convenient / appear risk-free by working as seamlessly as new
> installs or upgrades.

Just seen a situation which would not have astonished me, were it not for
this clarification about pinning: on a mostly-testing machine, where upgrading
tulip to new 4.8.0 from unstable (I had a pre-upload locally-built version of
that package installed, with same version string, but I'm not sure that makes
any difference) pulls binutils from unstable, breaking a couple of binutils-related versionned deps:

* the first suggestion is to remove tulip (the same kind of choice which puzzles
  me with downgrade: it has been marked for upgrade, why on earth is the *first*
  suggestion to do anything else than what was asked)
* then after I refused this choice for tulip, the next suggestion is to keep the
  currently installed version (same remark)
* then the next one is to upgrade binutils (and -dev and -multiarch), which is
  what I would have expected at first, BUT at the same time to DOWNGRADE
  binutils-arm-linux-gnueabi to the version in "stable"
* refusing that downgrade it finally proposes to upgrade the latter to unstable
  as well

That's the kind of situation to which I am routinely subject, and to which
unfortunately I usually don't pay that much attention any more.  But your
remark about pinning being the mechanism getting in the way of voluntary
downgrades, which perfectly made sense at the time, now confuses me, as I
don't see how it could cause a downgrade to be prefered to an upgrade.

Maybe the reason is linked to the identical score of 500 reported
by apt-cache policy ?