If I try to emerge kdevelop I get: # emerge -p kdevelop These are the packages that would be merged, in order: Calculating dependencies... done! emerge: there are no ebuilds built with USE flags to satisfy ">=x11-libs/qt-sql-4.6.3:4[qt3support]". !!! One of the following packages is required to complete your request: - x11-libs/qt-sql-4.7.3 (Change USE: +qt3support) (dependency required by "dev-util/kdevelop-4.2.2" [ebuild]) (dependency required by "kdevelop" [argument]) What? # emerge -p qt-sql These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] x11-libs/qt-sql-4.7.3 USE="exceptions iconv qt3support sqlite (-aqua) -debug -firebird -freetds -mysql -odbc -pch -postgres" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB So I though I'd add "qt3support" to all x11-libs/qt* pacakges and the one that really had it missing was x11-libs/qt-assistant. # echo "x11-libs/qt-assistant qt3support" >> /etc/portage/package.use # emerge -p kdevelop These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] x11-libs/qt-assistant-4.7.3 USE="exceptions glib qt3support (-aqua) -compat -debug -doc -pch -trace" 0 kB [ebuild N ] dev-util/kdevplatform-1.2.2 USE="git subversion (-aqua) -cvs -debug (-kdeenablefinal) -reviewboard -test" LINGUAS="sv -ca -ca@valencia -da -de -en_GB -es -et -fr -it -nb -nds -nl -pt -pt_BR -ru -sl -th -uk -zh_CN -zh_TW" 1,710 kB [ebuild N ] sys-devel/gdb-7.2 USE="nls python -expat -multitarget -test -vanilla" 18,106 kB [ebuild N ] kde-base/kapptemplate-4.6.3 USE="handbook (-aqua) -debug (-kdeenablefinal) (-kdeprefix)" 5,934 kB [ebuild N ] dev-util/kdevelop-4.2.2 USE="cmake cxx qmake qthelp (-aqua) -debug (-kdeenablefinal) -okteta -test" LINGUAS="sv -ca -ca@valencia -da -de -en_GB -es -et -fr -it -nb -nds -nl -pt -pt_BR -ru -sl -th -uk -zh_CN -zh_TW" 4,868 kB Total: 5 packages (5 new), Size of downloads: 30,615 kB Reproducible: Always
This is the --autounmask code, which is enabled by default now.
Is there emerge output in comment 0 complete? (e.g. are there autounmask comments, skipped update messages, ...). It looks to me like the autounmask code thought some change was necessary, but failed later when another change was needed. Maybe it run out of backtracking loops. This could have lead to a strange message, because if backtracking fails we rerun with only some of the changes. If there is no other output, attach the output of the first command with --debug added. You can also try the first command with --backtrack=30 and see what it gives.
It seems like the _pkg_use_enabled logic might be flawed, since it grabs old_use from needed_use_config_change sometimes, and then can generate new_changes from that so that new_changes actually reverts back to the user's existing configuration. It seems odd that this sort of new_changes would ever be recorded in needed_use_config_changes. Maybe we need to compare them to the original config and drop them if there's no difference, or something like that.
Also, this code from _show_unsatisfied_dep seems suspicious: for flag in involved_flags: if flag in self._pkg_use_enabled(myparent): changes.append(colorize("blue", "-" + flag)) else: changes.append(colorize("red", "+" + flag)) It's using the flags from _pkg_use_enabled to decide what changes to display, when the user's existing settings could already match those changes.
(In reply to comment #3) > It seems like the _pkg_use_enabled logic might be flawed, since it grabs > old_use from needed_use_config_change sometimes, and then can generate > new_changes from that so that new_changes actually reverts back to the user's > existing configuration. It seems odd that this sort of new_changes would ever > be recorded in needed_use_config_changes. Maybe we need to compare them to the > original config and drop them if there's no difference, or something like that. Isn't there a check to prevent it from reverting its own changes? (In reply to comment #4) > Also, this code from _show_unsatisfied_dep seems suspicious: > > for flag in involved_flags: > if flag in self._pkg_use_enabled(myparent): > changes.append(colorize("blue", "-" + flag)) > else: > changes.append(colorize("red", "+" + flag)) > > It's using the flags from _pkg_use_enabled to decide what changes to display, > when the user's existing settings could already match those changes. There is no problem as long as involved_flags contains only changed flags.
Created attachment 274505 [details] emerge -pv --debug --backtrack=30 dev-util/kdevelop
Created attachment 274507 [details] emerge --info Thought it might be of intrest.
Looks like I was right in comment 2. The message is garbage because some of the changes made during backtracking aren't used in the last run. I think we need to: 1) Add debug output to the autounmask code. 2) Stop running the dep resolution again with only parts of the changes. I think we get better error messages in the end. That might need some work too. We should probably add code like the missed update code that prints a reason for packages masked by backtracking.
Is there anything else/more I can add to this in the meantime?
(In reply to comment #9) > Is there anything else/more I can add to this in the meantime? The following might be interesting too. # echo "x11-libs/qt-assistant qt3support" >> /etc/portage/package.use # emerge -p kdevelop --complete-graph=y
> # emerge -p kdevelop --complete-graph=y # emerge -p kdevelop --complete-graph=y These are the packages that would be merged, in order: Calculating dependencies... done! emerge: there are no ebuilds built with USE flags to satisfy ">=x11-libs/qt-sql-4.6.3:4[qt3support]". !!! One of the following packages is required to complete your request: - x11-libs/qt-sql-4.7.3 (Change USE: +qt3support) (dependency required by "dev-util/kdevelop-4.2.2" [ebuild]) (dependency required by "kdevelop" [argument]) Same.
(In reply to comment #11) > Same. Did you really add echo "x11-libs/qt-assistant qt3support" >> /etc/portage/package.use ? If yes, run the same command with --backtrack=0.
> Did you really add > echo "x11-libs/qt-assistant qt3support" >> /etc/portage/package.use ? No, sorry, brainfreeze. # echo "x11-libs/qt-assistant qt3support" >> /etc/portage/package.use # emerge -p kdevelop --complete-graph=y These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] x11-libs/qt-assistant-4.7.3 USE="exceptions glib qt3support (-aqua) -compat -debug -doc -pch -trace" 0 kB [ebuild N ] sys-devel/gdb-7.2 USE="nls python -expat -multitarget -test -vanilla" 0 kB [ebuild N ] kde-base/kapptemplate-4.6.3 USE="handbook (-aqua) -debug (-kdeenablefinal) (-kdeprefix)" 0 kB [ebuild N ] dev-util/kdevplatform-1.2.2 USE="git subversion (-aqua) -cvs -debug (-kdeenablefinal) -reviewboard -test" LINGUAS="sv -ca -ca@valencia -da -de -en_GB -es -et -fr -it -nb -nds -nl -pt -pt_BR -ru -sl -th -uk -zh_CN -zh_TW" 0 kB [ebuild N ] dev-util/kdevelop-4.2.2 USE="cmake cxx qmake qthelp (-aqua) -debug (-kdeenablefinal) -okteta -test" LINGUAS="sv -ca -ca@valencia -da -de -en_GB -es -et -fr -it -nb -nds -nl -pt -pt_BR -ru -sl -th -uk -zh_CN -zh_TW" 0 kB Total: 5 packages (5 new), Size of downloads: 0 kB
Playing around with this. Without "qt3support" enabled for x11-libs/qt-assistant, I tried: # emerge -p kdevelop qt-assistant These are the packages that would be merged, in order: Calculating dependencies... done! The following USE changes are necessary to proceed: #required by x11-libs/qt-assistant-4.7.3, required by qt-assistant (argument) >=x11-libs/qt-declarative-4.7.3 -qt3support #required by x11-libs/qt-assistant-4.7.3, required by qt-assistant (argument) >=x11-libs/qt-gui-4.7.3 -qt3support #required by x11-libs/qt-assistant-4.7.3, required by qt-assistant (argument) >=x11-libs/qt-sql-4.7.3 -qt3support emerge: there are no ebuilds built with USE flags to satisfy ">=x11-libs/qt-sql-4.6.3:4[qt3support]". !!! One of the following packages is required to complete your request: - x11-libs/qt-sql-4.7.3 (Change USE: +qt3support) (dependency required by "dev-util/kdevelop-4.2.2" [ebuild]) (dependency required by "kdevelop" [argument]) This message is even more confusing... With "qt3support" enabled on x11-libs/qt-assistant it works as expected.
(In reply to comment #8) > 2) Stop running the dep resolution again with only parts of the changes. I > think we get better error messages in the end. That might need some work too. For awhile, we didn't use backtracker.get_best_run(), but then I hit a case where it was needed to work as well as autounmask/backtracking with 2.1.9.x, and added it back in: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=a7c3400c1c8022b5b1b00e1d5b871bf902b25f48 I've reproduced the confusing "x11-libs/qt-sql-4.7.3 (Change USE: +qt3support)" message with both 2.1.9.x and 2.2.x. I'm thinking making handle this case by discarding all the backtrack data and doing a fresh depgraph with no autounmask settings.
(In reply to comment #15) > I'm thinking making handle this case by > discarding all the backtrack data and doing a fresh depgraph with no autounmask > settings. This is implemented now: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=20498936b79906dfcb31a84cfd9e97ee20c94147 With this patch, the emerge output looks like this: emerge: there are no ebuilds built with USE flags to satisfy "~x11-libs/qt-sql-4.7.3[aqua=,debug=,qt3support=,sqlite]". !!! One of the following packages is required to complete your request: - x11-libs/qt-sql-4.7.3 (Change USE: -qt3support) - x11-libs/qt-assistant-4.7.3 (Change USE: +qt3support) (dependency required by "x11-libs/qt-assistant-4.7.3" [ebuild]) (dependency required by "dev-util/kdevelop-4.2.2[qthelp]" [ebuild]) (dependency required by "kdevelop" [argument])
This is fixed in 2.2.0_alpha36.
The problem with this approach is that we are back in the old days where people have to fix one conflict after another. Assume the user has 5 conflicts and only the last one is not solvable. Then the user has to fix the first 4 to get down to the real problem. Those 4 could easily include solvable slot conflicts and other annoying stuff that's trivial to ignore. We should really try hard to get away without rerunning the dep calculation after the last failed backtrack. You could print a warning in this case that backtrack=0 gives the original conflicts.
I'm definitely in favor of creating a more optimal solution. However, the output shown in comment #0 certainly represented a major regression relative to the output shown in comment #16. If given a choice between these two outputs, the choice is obvious.
The output in comment 0 garbage, agreed. But the way it is created is bogus. Using only partial backtracking paramaters is not the way to go. We should use all of them. I need to add a correction to my last comment. We shouldn't use the last run, but the first leaf node of the backtracking graph found by depth first search. This is the most promising run.
