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 ?
