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

[ydirson at free.fr]

Hi Manuel,

----- Mail original -----
> >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.

I understand, but for this a warning like we already have eg. for removal
of (essential?) packages should be enough.


> >[...]
> >     Remove the following packages:
> >1)     iceweasel-dbg
> >
> >     Keep the following packages at their current version:
> >1)     iceweasel [7.0.1-1 (now, unstable)]
> >
> >     Upgrade the following packages:
> >5)     iceweasel [7.0.1-1 (now, unstable) -> 8.0~b1-1
> >(experimental)]
> >
> >      Downgrade the following packages:
> >6)      iceweasel [7.0.1-1 (now, unstable) -> 3.5.16-6 (stable)]
> >
> >[here after a number of combinations involving downgrade to 3.5, I
> >had
> >to reject that line manually]
> >
> >     Downgrade the following packages:
> >5)     iceweasel [7.0.1-1 (now, unstable) -> 3.6.23-1 (wheezy)]
> >
> >then the dreaded...
> >
> >open: 5318; closed: 48906; defer: 141; conflict: 187
> >No solution found within the allotted time.  Try harder? [Y/n]
> >open: 10316; closed: 72787; defer: 141; conflict: 187
> >No solution found within the allotted time.  Try harder? [Y/n]
> 
> Perhaps you can try the interactive resolver, it is quite useful in
> any
> situation where the resolver gets stuck and one wants to guide the
> resolution to a quick end.

I *am* using the interactive resolver all the time, it's just that it's
much harder to use demonstratively for a bugreport :)

And even interactively, having to explicitly refuse *several times* suggestions
that are *contrary* to what the user asked is still frustrating, and just does
not feel right.

Thinking about it with pinning in mind, maybe it would just be worth and
sufficient to use a large priority to versions explicitly requested by the user,
together with a bold "you're going to downgrade packages, to your own risk" warning ?