[Aptitude-devel] Bug#762932: Bug#762932: aptitude: in an upgrade with 'U', aptitude chose to downgrade a package

Mon Sep 21 13:11:13 UTC 2015

(I am replying to clarify some points, but I am not going to continue
arguing about this).

2015-09-21 13:40 GMT+01:00 Vincent Lefevre <vincent at vinc17.net>:
> Hi,
>
> On 2015-09-21 12:43:08 +0100, Manuel A. Fernandez Montecelo wrote:
>> The website also says:
>>
>>  http://www.debian.org/releases/
>>
>>  unstable
>>
>>  The unstable distribution is where active development of Debian
>>  occurs. Generally, this distribution is run by developers and those
>>  who like to live on the edge.
>>
>> And:
>>
>>  http://www.debian.org/releases/sid/
>>
>>  sid is subject to massive changes and in-place library updates. This
>>  can result in a very unstable system which contains packages that
>>  cannot be installed due to missing libraries, dependencies that cannot
>>  be fulfilled etc. Use it at your own risk!
>
> Basically, two things are said:
>
> 1. Some packages cannot be installed (for some period), which is OK
>    for me, and this cannot be avoided.

Fine, that must be one of the solutions offered.  What is wrong with
navigating to that solution and accept it, disregarding the *offer* to
downgrade?

> 2. Things may break due to active development, but I think that
>    everyone should agree that this should be regarded as a bug.

The bug is present since many years ago, despite which people continue
to use aptitude happily.  It was never removed because this behaviour
rendered it unusable and harmful for the rest of the system.

Note that it's not that I don't agree that it's a bug, rather on the severity.

>> According to the original bug message, you use unstable by default and
>> experimental (also known as rc-buggy):
>>
>>  APT prefers unstable
>>  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
>
> I've just enabled experimental, but it has priority 1, meaning that
> such packages should never be installed automatically, as described
> in apt_preferences(5). This is for APT, but I expect aptitude to
> follow these rules. Unfortunately it doesn't and silently upgrades
> packages to experimental; that's bug 795228.

Yup.  Is that bug more important/critical/risky or less than this one? ;-)

>> I am sure that you are aware about all of this.  But in this case, you
>> are also aware that upgrades not strictly from one stable to the next in
>> Debian are not supported, much less mixing 4 distributions (with 3/4
>> versions of each packages and multiple possibilities to conflict),
>> including unstable and experimental at random points in time, including
>> huge transitions between releases, as we have now (and this is like the
>> worst time in a decade).
>
> No, upgrades should still be supported as long as packages are in
> official Debian repositories, and according to a recent discussion,
> this should include upgrades from experimental.

Upgrades do often work and are the default solution.  There are times
when they are impossible to satisfy.  With non-default options, you
got the offer to downgrade.

I cannot see how a solution that you got offered, possibly due to not
using the default options, and didn't like, breaks the general rule.

(Even then, I haven't participated in the discussion, but things other
than stable are not well supported in Debian.  And even in that case
everything is best effort.  Volunteer work and such.).

>> If I ask aptitude to upgrade a package and the dependencies cannot be
>> fulfilled (as explained above for unstable), it is natural that aptitude
>> tries to come up with weird solutions.  That includes downgrading.
>
> I disagree. It is natural that aptitude follows the apt_preferences(5)
> rules by default, at least no automatic installation of experimental
> packages (priority 1) and excluding downgrading except in specific
> cases:
>
>   · 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.)
>
> By default, aptitude should just block the upgrade of packages that
> don't satisfy the dependencies.

By default it probably does, because I can't remember if I was ever
offered a downgrade.  Again, you were using non-default options.

Note also about full-upgrade:

       full-upgrade

           Upgrades installed packages to their most recent version, removing
           or installing packages as necessary. This command is less
           conservative than safe-upgrade and thus more likely to perform
           unwanted actions. However, it is capable of upgrading packages
           that safe-upgrade cannot upgrade.

So, in short, if you don't want surprises, probably you should use
"safe-upgrade" and not "full-upgrade -y".

>> To me, is a bit like assigning critical to dpkg because "dpkg -i
>> ${random-deb}" also allows you to downgrade (without even asking!), or
>> to coreutils because a mistaken "rm" can cause "accidental data loss"
>> and doesn't even tell you which files it removed in the default config.
>
> If both cases, that's a user fault (dpkg is a low-level tool,
> contrary to APT and APT-based tools).

rm is also a low level tool that should not be used by common users, I suppose.

apt, aptitude and dpkg are su-level, low level and mess with your
system as whole.

>> I assume that this works as intended and doesn't like solutions like
>> removing obsolete libraries (of which there are lots lately, specially
>> after the *v5 mass-renaming for example and with gcc-5 adding lots of
>> "breaks" to some packages), so maybe it doesn't have better options (in
>> terms of "resolver costs") than to downgrade.
>
> No, the best solution is to require the user to solve the problem
> manually.

Well, it idoes, it offered you a solution, as far as I am aware, for
you to decide.  Only when passing "-y" it didn't, and rightly so.

> Well, I wish there were a way to remove libraries
> automatically (since they are typically installed as dependencies),
> but this doesn't seem to be possible with aptitude. And without
>
>   Aptitude::ProblemResolver::SolutionCost "removals";
>
> aptitude sometimes wants to remove most of the system, making 'U'
> in the UI completely useless!

Yup.  Is that bug more important/critical or less than this one? ;-)

Pro-tip: the second solution often does what you want (with the
default config at least).

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