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

[Manuel A. Fernandez Montecelo]

Hi,

2015-09-20 20:20 Vincent Lefevre:
>
>> I'd don't consider this "grave" at all, as it neither "makes the
>> package in question unusable or mostly so", nor "causes data loss",
>> nor "introduces a security hole allowing access to the accounts of
>> users who use the package".
>
>Well, then it should be "critical" because
>
>  https://www.debian.org/Bugs/Developer.en.html
>
>says "makes unrelated software on the system (or the whole system)
>break" (not all downgrades break the system, but this is a possibility).

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!


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

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.  So
if I want to upgrade the version of 10 packages in unstable, and they
depend on the new libstdc++6, and there is one dependency from
experimental (libmad1.1) which had been compiled against the old
libstdc++6 while there is "libmad1.0" in unstable compiled against the
new libstdc++6, is is natural and reasonable that aptitude offers me a
downgrade -- it is the easiest way to satisfy upgrading 10 packages and
just downgrading one, without removals or other also negative effects.

I am the master juggling blades, I am using unstable and experimental, I
tweak the resolver parameters to my heart's content, I ask to upgrade
things in the middle of a terribly complicated transition, and aptitude
does not treat me like as an idiot: it *offers* me a *possible solution*
to the conflicting states after an action that I *requested*, that
includes downgrades.  It didn't break my system just casually like
sitting there on the filesystem, or while doing "aptitude update", or
when reinstalling a package, or upgrading from one stable to the next.

I don't see anything wrong with that, that is part of the core function
of aptitude, to put me in charge.  In fact, I would be disappointed if
aptitude didn't offer me slightly awkward solutions that would fit the
bill sometimes.

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.

aptitude is perfectly usable by thousands of people every day for years
without major risks, there is nothing grave or critical about its
behaviour.


Another question is if the downgrades themselves are sensible (what the
original messages were about), when there would be another better
solutions -- I fully agree that there are lots of problems and a big
room for improvement.


>> I though never ran into that issue (despite having
>> Aptitude::ProblemResolver::Remove-Level set to "maximum" which should
>> have a very similar effect), so I assume that possible further
>> non-default settings could have caused this. Please post all your
>> Aptitude resolver related settings (or confirm that the above
>> mentioned setting is the only one).
>
>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.


The default option is:

  The default cost, sorting solutions by their safety cost, then by
  their apt pin priority:
  
  safety, priority


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