[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 16:50 ydirson at free.fr:
>
>> 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.
>>
>>[...]
>> 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)

As you say above, it is a matter of trade-offs and balances.

In hundreds of bugs still open in aptitude, only a couple of them that I
just fixed (the ones about "not downgrading even when pinning > 1000")
and this one are about *wanting* to downgrade.  There are a few other
bugs complaining about downgrades even being suggested as a solution,
after tweaking the default costs of the resolver [1] -- and suggestions
that are clearly advertised as downgrades and that one can reject
anyway.

There are no mentions about downgrades in the change log of aptitude
between 2007 and 2015, and then in 2007 is only to forbid them in
safe-upgrade and making them more visible, then in 2005 and
2004... etc... always in the direction of making the downgrades more
noticeable and less likely to happen, never to facilitate them.


Downgrading is possible, even if laborious sometimes.  They are
laborious among other reasons because rev-depends always keep increasing
the version required of their dependencies, so downgrading will always
involve the same or more changes in other packages than upgrades, and
the resolver will always be happier to suggest other actions rather than
downgrades -- as it should be.

The recently added fix of 0.7.5 should help in the cases when there are
many packages wanting to be downgraded to the same suite (e.g. testing
from unstable, or unstable from external repositories).  Maybe you can
try to see if it helps when it becomes too laborious to pick solutions
one by one.


The simple fact is that for the moment I am quite scared of changing the
current behaviour of the resolver of aptitude, and maybe creating a
bigger mess of it than what it currently is.

I don't believe that helping to do downgrades is a powerful reason worth
risking further breakage by tweaking the resolver -- not at this point
or in the near future anyway.


[1] That's another thing that some people use to improve suggestions of
    the resolver, I never use them by default and very rarely played
    with them though:

    http://aptitude.alioth.debian.org/doc/en/ch02s03s04.html


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