2015-12-07 21:40 ydir...@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.montez...@gmail.com>
