Bug 615680 – sys-apps/portage: automatically disable backtracking if autounmask changes are needed, and add --autounmask-backtrack=<y|n> option

• Product: Portage Development
• Status: RESOLVED FIXED

[Description Zac Medico 2017-04-15 22:06:32 UTC]

Problem: It's typically a poor idea to perform emerge calculations that will require both autounmask changes and backtracking, since it's likely that the calculation will ultimately fail after wasting a lot of time backtracking. This is the reason for the low default --backtrack setting from bug 536926.

Solution: Make emerge automatically disable backtracking when it finds that autounmask changes are needed, and add a --autounmask-backtrack=<y|n> option that can be used to explicitly enable or disable backtracking with autounmask. When emerge bails out early, make it notify the user about the --autounmask-backtrack=y option is available, but also warning that the option is not generally recommended because it can waste a lot of time.

[Comment 1 Zac Medico 2017-04-15 22:23:02 UTC]

The --autounmask-continue option should imply --autounmask-backtrack=y, because otherwise users of --autounmask-continue will find that if fails where it once succeeded.

[Comment 2 Zac Medico 2017-04-15 23:20:44 UTC]

In addition to autounmask config changes, other foreshadowers of backtracking failure include blockers and slot conflicts. However, it's often difficult to predict whether or not blockers and slot conflicts will ultimately be solved by backtracking, so we can't predict when user intervention will be necessary.

For autounmask config changes, user intervention is always necessary, so we can change the default behavior without breaking anyone's automated emerge calls (but --autounmask-continue must imply --autounmask-backtrack=y for backward compatibility).

[Comment 3 Zac Medico 2017-04-17 05:25:42 UTC]

I'm working on a patch in this branch:

https://github.com/zmedico/portage/tree/bug_615680

Six of the existing cases fail unless --autounmask-backtrack=y is added to the options. It looks like the behavior can be improved for some of these without too much work, so I'm planning submit a series of patches to improve the behavior. After my improvements, at least some of the test cases should succeed without having to add --autounmask-backtrack=y to the options.

[Comment 4 Zac Medico 2017-04-24 07:44:51 UTC]

Only 5 tests now required --autounmask-backtrack=y to succeed. The behavior seems acceptable for these cases when --autounmask-backtrack=y is not enabled.

Before I submit the patch for review, I just need to update it to display a suggestion about --autounmask-backtrack=y when appropriate.

[Comment 5 Zac Medico 2017-05-10 03:57:52 UTC]

Patch posted for review:

https://archives.gentoo.org/gentoo-portage-dev/message/12b068cdecbf85209fcc5782b127907e
https://github.com/gentoo/portage/pull/162

[Comment 6 Zac Medico 2017-05-14 18:22:28 UTC]

This is in the master branch:

https://gitweb.gentoo.org/proj/portage.git/commit/?id=40505ceeadc769f4f01c66e52a19ce0bf2f59761

[Comment 7 Zac Medico 2017-05-20 18:33:20 UTC]

Fixed in portage-2.3.5.

[Comment 8 Zac Medico 2017-05-20 18:57:34 UTC]

Actually this is in portage-2.3.6.

[Comment 9 Zac Medico 2017-08-11 19:44:17 UTC]

Fixed in 2.3.6.