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

[Vincent Lefevre]

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.

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

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

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

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

> 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).

> >Aptitude::UI::Package-Display-Format "%c%a%M %p %Z %24v %24V";
> >Aptitude::ProblemResolver::SolutionCost "removals";
> 
> According to the documentation, "removal" means: "Counts the number of
> packages that the solution removes".
> 
> 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, 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!

-- 
Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)