[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: