[Aptitude-devel] Bug#817776: [aptitude] SIGABRT when quitting curses mode after unresolvable conflicts

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi again,

2016-03-10 10:53 To Katsuhiko Nishimra:
>2016-03-10 01:03 Katsuhiko Nishimra:
>>Package: aptitude
>>Version: 0.7.8-1
>>Severity: minor
>>
>>Dear maintainers,
>>
>>As I mentioned in a former bugreport[1], aptitude gets SIGABRT when
>>quitting curses session after too many conflicts that aptitude cannot
>>resolve automatically.
>>
>>How to reproduce:
>>* Make aptitude gets a lot of conflicts (e.g. Install conflicting
>>  packages by dpkg and upgrade/downgrade many packages)
>>* Get the prompt `Resolve these dependencies by hand? [N/+/-/_/:/?]'
>>  and hit `e' to enter curses mode
>>* Quit aptitude leaving package state unresolved by hitting `q'
>>
>>A backtrace from a dumped core is attached.
>>I hope it helps you.
>
>I see, our friend boost::flyweight again... thanks!

I think that I solved the problem in a similar way as the other one.

The problem is that I cannot reproduce the situation by getting the
"Resolve these dependencies by hand?", so I cannot test whether it
worked or not.

I forcibly install and remove some packages with dpkg to conflict with
installed ones, and then do a variety of actions (upgrades, purges etc;
of important packages such as libc6 or systemd), using full resolver,
safe resolver, enabling and disabling auto-fix-broken... but in all
cases, either I get the typical prompt "Accept solution?" or the
resolver spends lots and lots of time (> 10 minutes) trying to solve the
problem without offering me to resolve by hand.

I cannot to afford at this moment to try too hard and risk breaking the
system for real, so it would be very nice if you (or other readers)
could check if this indeeds solves the situation in the next release and
report back whether it worked or not -- I am quite confident that it
does, so marking as +pending.


... and thanks for the detailed reports and persistence, in any case!


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>