On Tue, Jan 24, 2017 at 12:21:14PM +0100, Thorsten Glaser wrote:
> When a package is installed in multiple architectures, such as…
>
> tglase@tglase:~ $ apt-cache policy libpsl5{,:i386}
> libpsl5:
> Installed: 0.16.1-1
> Candidate: 0.17.0-2
[…]
> libpsl5:i386:
> Installed: 0.16.1-1
> Candidate: 0.17.0-2
[…]
> … please do not consider upgrading only one of it when the other one
> cannot be upgraded at the same time (i.e. when it must be removed),
> even in an apt-get dist-upgrade.
In your example the M-A:same packages are version-synced. In fact, apt
actually notices a version-desync and would not consider the upgrade in
that case (expect for some corner cases like if the package is dropped
on that arch and such or if you explicitly request install of the
package, …), so part of that request is already done and in full effect.
What remains is:
> Scenarios for this include…
>
> • both new versions are there, consistent, but cannot be installed
> because they depend on a not coïnstallable package (cf. #852408,
> which is the case for libpsl5 here)
In the current apt solver implementation that is nearly impossible to do
as decisions are formed on a per package base in a greedy fashion – we
have some forms of back- and forwardtracking and that catches some easy
cases, but that can't reasonably deal with the general hard cases as
these involve whole clusters of packages.
Other solver implementation are better at that – they have other
disadvantages in exchange. Keeping better track of which decision was
taken why is on the ever-growing todolist, but as it a major project its
unlikely to happen soon if ever.
> • the new version is not coïnstallable any more (the local admin
> SHALL decide in that case which one to throw away)
That is one of the cornercases mentioned above – apt in its usual
fashion will decide for you based on what your system seems to need
"most" simply because it would be horrible if we ask the user for input
each time (one of these days I have to implement a solver which asks the
user all the time if there is a choice… people are so going to hate it)
e.g. the user drops a foreign arch. And apt is asking for input
anyhow: Its proposed solutions aren't set in stone, if you don't like
them you can press 'no' and help it find another:
> … but are not limited to these, they are just the ones I can think of.
> I’m running into such cases often (especially because binNMU version
> skew is still a blocker for coïnstallability despite us having been
> promised years(!) ago that it won’t be “soon”); usually, I run an
> “upgrade --with-new-pkgs” first, but sometimes that completely fails
> (apt aborts because it cannot find a solution) which means I must set
> some of the involved packages to hold… and remember to un-hold them
> later (tricky because I have certain packages — virt-manager & Co.
> and mailman — on hold for different reasons which they must stay on,
> so I cannot just use --ignore-hold or automatically unhold everything).
You can specify after (dist/full-)upgrade packages which will be
installed (or removed if postfixed with a -) and hence help the solver
figure out "your" solution. There is no "temp" hold at the moment apart
from asking apt to install a package already installed, but that might
be added some time in the future.
Best regards
David Kalnischkies
Attachment:
signature.asc
Description: PGP signature