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

[Manuel A. Fernandez Montecelo]

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.


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


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