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.montez...@gmail.com>
