2d65d5b7bf
In certain extreme situations, that are more likely if the install state is old (e.g. 9 months +), Entropy may decide to remove packages due to conflicts with the version being installed and shoot itself in the foot, if this is the case of dev-lang/python :-). So, this commit tries to avoid the scenario by filtering out package removals for those that are being installed anyway as part of the transaction (e.g. a system upgrade). This should fix the very specific case, but increase uncertainty and thus entropy in other cases where once a package that lists conflicts is installed, it may not expect to find that package installed. However, this case should be handled by the dependency graph generator (and it currently does not), which would need to reorder the execution of the queue to comply with conflicts. Perhaps, someone in the future will improve that too, for now, let's enjoy one more snowflake. Current improvement: - foo-1 and bar-2 are set to be installed - foo-1 conflicts with <bar-2 - bar-1 is installed - foo-1 wanted to remove bar-1 as part of foo-1 install transaction. (now fixed, it won't...) - bar-2 is then installed Better improvement: - foo-1 and bar-2 are set to be installed - foo-1 conflicts with <bar-2 (but bar-2 itself can be installed and does not conflict with foo-1) - bar-2 is set to be installed before foo-1 - when entropy gets to foo-1 there is nothing to remove