[Aptitude-devel] Bug#740750: MarkInstall resets candidate, breaks interactive problem resolution

[Daniel Hartwig]

(Discussion started here:
<https://lists.debian.org/deity/2014/03/msg00015.html>)

On 12 March 2014 01:21, David Kalnischkies <david at kalnischkies.de> wrote:
> On Tue, Mar 11, 2014 at 12:11:57PM +0100, David Kalnischkies wrote:
>> On Thu, Mar 06, 2014 at 10:24:37AM +0800, Daniel Hartwig wrote:
>> >  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).
>>
>> 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.
>
> Attached are two changes which should implement it this way and I guess
> are better suited to fix the problem as they remove this specific
> loopbreaking from MarkInstall and moving it to IsInstallOk which a
> frontend can override and hence disable this and/or other checks.
>
> I can see in the aptitude code that you are overriding this method
> already, so in case we would go with this everything should magically
> work for aptitude again as it used to be back in the "old days", right?
> Or is there something I am missing?
>

Correct.  It is working as previously now, thank you.  I am
reassigning the regression report (#740750) for your closing.

> Looking with codesearch suggests that no other frontend is playing with
> IsInstallOk, so the behavior changes only in so far that breakage
> (introduced in May 2011, so it might very well be expected behavior now)
> is now more obvious as the loop is not even started instead of broken
> somewhere down the line, which sounds like a good thing and an easy way
> out of this problem is present as well if need be.
>

I was surprised that I could not reproduce this in synaptic, though
IIRC they use pinning ("force version" in their lingo) to change the
candidate.


Thank you for your quick response on this issue.

Regards

Daniel Hartwig