[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 21:40 ydirson at free.fr:
>> 2011-10-01 15:59 Yann Dirson:
>> >Package: aptitude
>> >Version: 0.6.3-4
>> >Severity: normal
>> >
>> >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.
>
>Just seen a situation which would not have astonished me, were it not for
>this clarification about pinning: on a mostly-testing machine, where upgrading
>tulip to new 4.8.0 from unstable (I had a pre-upload locally-built version of
>that package installed, with same version string, but I'm not sure that makes
>any difference) pulls binutils from unstable, breaking a couple of binutils-related versionned deps:
>
>* the first suggestion is to remove tulip (the same kind of choice which puzzles
>  me with downgrade: it has been marked for upgrade, why on earth is the *first*
>  suggestion to do anything else than what was asked)
>* then after I refused this choice for tulip, the next suggestion is to keep the
>  currently installed version (same remark)

This is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=359171 ,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574132 and many
others.

Very often, the first suggested solution is outright bad, one of the
next few ones if often good.


>* then the next one is to upgrade binutils (and -dev and -multiarch), which is
>  what I would have expected at first, BUT at the same time to DOWNGRADE
>  binutils-arm-linux-gnueabi to the version in "stable"
>* refusing that downgrade it finally proposes to upgrade the latter to unstable
>  as well
>
>That's the kind of situation to which I am routinely subject, and to which
>unfortunately I usually don't pay that much attention any more.  But your
>remark about pinning being the mechanism getting in the way of voluntary
>downgrades, which perfectly made sense at the time, now confuses me, as I
>don't see how it could cause a downgrade to be prefered to an upgrade.
>
>Maybe the reason is linked to the identical score of 500 reported
>by apt-cache policy ?

I am not sure about the root cause of this, neither the general problem
nor the specific suggestion to downgrade.

In general, I think that it's a good idea to have different priorities
for different suites (testing, unstable, etc), and not several of them
at the same level, because otherwise it makes the resolution more
difficult, and if two package versions have the same priority it can
recommend them randomly instead of prefering the solution of one suite.


The fact that the general problem was not successfully solved by the
original developer of aptitude, even after several refurbishments of the
resolver, and that probably he is the only person in the world who knows
in depth the aptitude resolver, doesn't seem like a good omen to resolve
it soon.

But in any case, as I explained in the previous messages, that's the
main reason why I don't want to tackle the problem of the downgrades in
particular: if things related with resolver are to be changed, it should
be to make the experience with everyday actions consistently good, not
to facilitate downgrades.  If as a side effect downgrades are made less
painful, fine (or maybe not fine and we have to restrict them
artificially to avoid people shooting themselves in the foot).  But the
modifications to the resolver should not be guided by facilitating
downgrades, they should first and foremost support well the everyday and
recommended actions -- good support from downgrades is far behind in the
list of priorities.


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