It's common for users to assume that they can run `emerge -u foo` and have it succeed even though lots of related packages or reverse dependencies may need to be updated at the same time. Their assumption is wrong because `emerge -u foo` really only gives the resolver permission to update foo. If any other updates are required, the command is intended to fail. There is no existing option that tells the resolver to "update any packages necessary" like people want in this case, so we should add one.
How common is it? Maybe we need to decide on a long-term path for making update do what you propose, where we move the old behaviour to a new option instead?
(In reply to Alexander Berntsen from comment #1) > How common is it? This is extremely common, especially for inexperienced users. With binary distros, partial update commands like this typically work, so it surprises them when they don't work with emerge. > Maybe we need to decide on a long-term path for making > update do what you propose, where we move the old behaviour to a new option > instead? That might work, but making the behavior of a particular emerge command vary from one portage version to another can lead to compatibility issues for people that rely on the existing behavior, and can be surprising/confusing for users.
(In reply to Zac Medico from comment #2) > (In reply to Alexander Berntsen from comment #1) > > How common is it? > > This is extremely common, especially for inexperienced users. With binary > distros, partial update commands like this typically work, so it surprises > them when they don't work with emerge. The behavior even surprises gentoo devs sometimes, making them think it's a bug. For example, see bug 558936, comment #3.
The idea of changing the meaning of --update seems to fit with the changes from bug 275945: https://gitweb.gentoo.org/proj/portage.git/commit/?id=5f32c4bf10301d154aa35aaf5653afeadcd520d6
While investigating a related test case at my workplace, I've found that simply adding --update --selective=n to the emerge options will solve the problem. The test case involved rebuilds being triggered, and the packages being rebuilt getting updated to new versions, which in turn triggered more rebuilds. Without --update --selective=n, backtracking failed because it kept pulling in some installed packages that needed to be rebuilt, triggering "backtracking loop detected" messages in the resolver debug output.
(In reply to Zac Medico from comment #5) Note that --selective=n is only needed if you want to force packages matched by arguments to be rebuilt, even if a matching version is already installed. Currently, there are some cases where simply adding --update to the options is not enough to solve it. For example, see the failing dependency calculation (with -u) from bug 558936, comment #0.
Until this bug is fixed and the option is enabled by default, we're going to need a FAQ entry for this. Users are frequently trying to do partial updates, and failing. For example, see bug 607244 and bug 607678.
I'm thinking that the option will be called --update-any, will be enabled by default, and disabled by --update-any=n.
I've added a question to the FAQ here: https://wiki.gentoo.org/wiki/Project:Portage/FAQ#Why_is_there_a_dependency_conflict_whey_I_attempt_to_upgrade_a_single_package.3F
This option will be most useful if it can trigger all of the updates after the first calculation, rather than triggering more an more updates with each backtracking calculation. As it is, backtracking can already trigger additional updates/rebuilds in order to solve conflicts. For example, when a subslot change triggers slot conflicts due to required rebuilds, those rebuilds can be triggered via _slot_operator_update_probe_slot_conflict even though the packages that need to be rebuilt happen to be reverse dependencies that are not reachable from the argument atoms.
*** Bug 802297 has been marked as a duplicate of this bug. ***