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

[Vincent Lefevre]

On 2015-09-21 14:11:13 +0100, Manuel A. Fernandez Montecelo wrote:
> 2015-09-21 13:40 GMT+01:00 Vincent Lefevre <vincent at vinc17.net>:
> > 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?

The first problem is that something not safe is proposed by default.
Even Debian developers do not want to allow the user to explicitly
downgrade (i.e. at the user's request) with apt:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=95427#29

The second problem is that this is not visible enough.

The third problem is that this is annoying.

> > 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? ;-)

Installing packages from experimental should not break things by design.

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

But the problem is the same since the goal of this non-default option
is just to avoid package removals.

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

I was using the UI (this is the reason I'm using aptitude and not
apt-get), and it appears that only something similar to "full-upgrade"
is available:

  "U":          Mark all upgradable packages to be upgraded.

as it is "full-upgrade" that gave me the same behavior as "U".

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

apt and aptitude are more high-level than dpkg, which does not have
the concept of priorities.

> > 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? ;-)

I find it more critical, but AFAIK, removing packages is supported by
Debian and not against Debian rules (except for essential packages).

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

But it is annoying to have to choose the second solution every time.

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