Fwd: MarkInstall resets candidate, breaks interactive problem resolution
---------- Forwarded message ----------
From: Daniel Hartwig <mandyke@gmail.com>
Date: 6 March 2014 10:24
Subject: MarkInstall resets candidate, breaks interactive problem resolution
To: David Kalnischkies <david@kalnischkies.de>, diety <diety@lists.debian.org>
Hi David, Deity
A common use case in aptitude, but also perhaps synaptic and others, is
to mark a version for install, inspect the broken dependencies, and
resolve the issues manually [1]. A recent change to MarkInstall has
upset this process by changing the candidate if some kind of broken
dependencies are found:
commit 446551c8ffd2c9cb9dcd707c94590e73009f7dd9
Author: David Kalnischkies <david@kalnischkies.de>
Date: Thu Feb 6 00:13:10 2014 +0100
discard impossible candidates in MarkInstall
If a (Pre-)Depends can't be satisfied there is no point in keeping the
candidate as is as it is impossible to find a solution for it, so we can
just as well reset the candidate to the currently installed version.
We avoid trying to install this impossible candidate later on this way.
Closes: #735967
I need to investigate also whether a previous change to call MarkDelete
under the same situation also impacts this use case.
Have you ideas about addressing the issue in an other way than modifying
candidate version in MarkInstall? Perhaps this logic is too frontend
specific for that function, although I see it is strictly related to the
solver.
Ideally I would like to have the flexibility in libapt and not have to
hack around issues or duplicate code inside aptitude, which has been
done extensively in the past and continues to cause issues.
Regards
Daniel Hartwig
[1] <http://bugs.debian.org/740750>
Reply to: