If portage-2.2 is called with a set evaluating to a sys-apps/portage update, portage reloads itself and re-evaluates the whole set. But if the portage update was the last atom of the merge, portage doesn't reload itself. I think we should get some consistency here, and either: a) do not re-evaluate sets and simply pass the remaining atoms when reloading, b) always reload portage when the dependency tree contained a set (even if the re-evaluation would result in an empty dependency tree).
I get the feeling that you're trying to solve some kind of problem without telling us what the problem is, and instead you're just telling us that the problem is "inconsistency". So, what's wrong with being "inconsistent"?
I'm simply solving the problem other way as I didn't like my original idea :P. But the facts are still facts. If we're supposed to re-evaluate the sets completely because the expansion result might differ between portage versions, we should do that even if the set currently evaluated to portage only.
(In reply to comment #2) > If we're supposed to re-evaluate the sets completely because the expansion > result might differ between portage versions, we should do that even if the set > currently evaluated to portage only. That's not the motivation for re-evaluation of sets. The set re-evaluation is merely a side-effect from portage needing to reload itself. When it reloads itself, it has to create a dependency graph because otherwise it wouldn't have a dependency graph to work with, and set evaluation is part of dependency graph creation.
