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

[Manuel A. Fernandez Montecelo]

Control: severity -1 wishlist
Control: tags -1 + wontfix
Control: close -1


Hi Yann,

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.


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


In summary, sorry but I don't consider that it's worth spending time in
an action that should happen rarely (if not avoided completely), when
aptitude already provides other means to achieve the desired outcome.

I am going to close the bug report, because after 4 years nobody was
interested in implementing this or even seconding it, it doesn't make
sense to keep it indefinitely gathering dust.


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