Imagine there are 1000 different combinations of
Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:
Remove the following packages:
1) libapt-pkg6.0 [2.7.12 (now, unstable)]
2) libglib2.0-0 [2.78.4-1 (now, unstable)]
Install the following packages:
3) libapt-pkg6.0t64 [2.7.12+nmu1 (unstable)]
4) libglib2.0-0t64 [2.78.4-2 (unstable)]
Keep the following packages at their current version:
5) at-spi2-core [2.50.0-1+b1 (now)]
6) gir1.2-atk-1.0 [2.50.0-1+b1 (now)]
7) libpam-modules [1.5.2-9.1+b1 (now)]
8) libpam-modules-bin [1.5.2-9.1+b1 (now)]
Accept this solution? [Y/n/q/?]
each of which we don't like. Well the only way to get out of it is
nnnnnn(500)nnnnn and finally q.
But q means we can't do the rest of the upgrade.
So there should be an additional "k" choice, to keep all shown,
and just proceed with the rest of the upgrade which isn't affected by
these shown.
There it finally was, way down at like the 31st choice.
Accept this solution? [Y/n/q/?] n
XX. The following actions will resolve these dependencies:
Keep the following packages at their current version:
1) apt [2.7.12 (now)]
2) apt-utils [2.7.12 (now)]
3) at-spi2-core [2.50.0-1+b1 (now)]
4) gir1.2-atk-1.0 [2.50.0-1+b1 (now)]
5) libglib2.0-bin [2.78.4-1 (now)]
6) libpam-modules [1.5.2-9.1+b1 (now)]
7) libpam-modules-bin [1.5.2-9.1+b1 (now)]
Accept this solution? [Y/n/q/?] n
First, there should be choice numbers shown, at point XX above.
Then in fact I could even easily say what choice it was. 31 is a guess.
OK, I'll file a separate bug about that.
Second, I was going too fast, with n RET n RET and ended up skipping
over it!
Thus we see you still need a "k" choice!
Sure, you are saying "hurry and send us the exact state of the package
system so we can recreate the issue."
But I'm saying it doesn't matter. Even if there was only one or two
choices before the all-keep choice popped up, there should always be my
proposed "k" option available.
And yes, "Well just use aptitide install ~U... _... ..._"
I am sure there are tons of workarounds. But that doesn't matter,
there still should be my proposed "k" short circuit choice!
Also even if at the 31st choice we finally get to keep all, the next day we will still be facing the same problem. Yes, usually it is just a temporary situation. Upstream was just in the middle of sending out some packages, etc. But even so, not for one minute should users be left digging for the 31st choice. So they should always have a "k" option.