Re: MarkInstall resets candidate, breaks interactive problem resolution
On 11 March 2014 19:11, David Kalnischkies <david@kalnischkies.de> wrote:
> On Thu, Mar 06, 2014 at 10:24:37AM +0800, Daniel Hartwig wrote:
>> 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:
>
> Why I am not surprised…
>
> Or, actually, I am. I nearly assumed that something would break, but
> aptitude was actually the least of my worries as I was under the
> impression that it doesn't do AutoInst=true at all.
>
>
>> commit 446551c8ffd2c9cb9dcd707c94590e73009f7dd9
> […]
>> I need to investigate also whether a previous change to call MarkDelete
>> under the same situation also impacts this use case.
>
> No idea really, but I would presume that if this is called for a "leaf"
> package it is just another unsatisfied dependency to be resolved.
> If on the other hand it is a request coming from the user it is
> protected by FromUser (assuming MarkInstall is called this way).
>
Which is not an issue for aptitude then, as we are always using FromUser.
> I wonder a bit how this all works at all though with this loopbreaking
> (the MarkDelete is just the topping) as it was introduced in df77d8a5
> (May 2011) by - surprise surprise - me. For interactive use it would
> probably be better to continue and let the user fix the breakage later.
>
> I guess we should move this check out into a IsInstallOk submethod so
> that you can at least disable this check (and we can stop at the
> beginning rather than somewhere in the middle). Will see if I can make
> this work.
>
>
>> 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.
>
> I am going to commit the attached 'compromise' which looks if there
> is a chance by candidate switching to make it work and if it is really
> impossible to make it work reset the candidate. This should deal with
> the initial problem of "package has no available version at all" and
> with more general "all available versions are crap" without going the
> shortcut over "the candidate version is crap". As I presume (even)
> interactive solvers can't make versions appear out of thin air,
> I hope that this works for all of us to some extend.
>
In some instances the user will mark for install some impossible
package, save and later restore that selection once it has become
possible, and proceed. In this case the compromise here is inferior
to the next patch (IsInstallOk) so I am pleased to see the later work
quite well.
>
>> 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.
>
> Sounds good. :) MarkInstall isn't the holy grail at the moment either
> though, unfortunately. It does way too much for my taste without a proper
> way to observe what it does from the outside. That it can't tell its
> caller (which most of the time is itself) that it is useless to explore
> certain dependency trees again (and again and again) is bad. Workarounds
> like this one only take us so far…
>
So if anyone is looking for an interesting task this summer .. :-)
>
> Best regards
>
> David Kalnischkies
Reply to: