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

[ydirson at free.fr]

----- Mail original -----
> De: "Manuel A. Fernandez Montecelo" <manuel.montezelo at gmail.com>
> À: "Yann Dirson" <ydirson at free.fr>
> Cc: 643997 at bugs.debian.org
> Envoyé: Lundi 7 Décembre 2015 17:30:46
> Objet: Re: aptitude: user-requested downgrade should not cause (so much of a) downgrade penalty for conflict
> resolution
> 
> 2015-12-07 15:17 GMT+00:00  <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 :)
> 
> Yes, that's true.
> 
> 
> > 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.
> 
> Are you using R and A to accept or reject individual package
> solutions?  That should help in this case, to avoid repeatedly
> getting
> suggestions that you don't want to accept.

Yes I do.  But I still have to individually refuse all "upgrade" and
"keep" suggestions, which all come with higher priority than the very
downgrade I had requested.  The typical case is that of a machine running
on "testing" (or even on "stable"), with sources.list entries for "unstable",
"experimental", (or "backports", "security" etc for "stable" boxes), etc to
facilitate targeted installation of newer versions when they are needed.

> 
> > 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 ?
> 
> If you pin the package or whole repository (e.g. mozilla.debian.net)
> in /etc/apt/preferences, or temporarily unstable in this case (see
> below), and do "aptitude install iceweasel* maybe-other-packages" or
> "aptitude upgrade iceweasel*", or "U" in curses, it should downgrade
> to the version in unstable.  (There are some bugs with the "upgrade"
> part though, that I am trying to address now, so I ).
> 
> Package: *
> Pin: release o=Debian,a=unstable
> Pin-Priority: 1001
> 
> 
> Regarding the warning, it does tell you in the command line
> separately
> ("the following packages are going to be DOWNGRADED") and it better
> highlights it in curses since a change that I did in the last few
> versions.
> 
> What I meant is that, in general, I think that time should better be
> spent in other features or more severe problems rather than in
> something that it's unsupported and discouraged to do anyway.
> 
> There are already some bugs/requests already complaining that users
> actions can lead to downgrades or installing versions in experimental
> "almost inadvertently" even when the user also requested those
> actions
> and insisting that they should have a high severity... so by making
> the feature more accessible in aptitude I can only foresee more of
> those reports.

Sure, but that may need to be balanced with the occasional need to
downgrade to avoid a blocking bug that inadvertently entered testing,
or just to check which package upgrade causes a bug to submit a
useful bugreport.

And I must say, I don't remember having been bitten by any downgrade,
at least recently.  Possibly because the bulk of what I downgrade is
libs, which are probably much less subject to downgrade problems
(although that's just a side-effect of how functionality is implemented
in various software)

> 
> Cheers.
> --
> Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>
>