Bug 559354 – sys-apps/portage: add emerge option which directs it to "update any packages necessary" (which --update does not do)

• Product: Portage Development
• Status: CONFIRMED ---

[Description Zac Medico 2015-09-01 20:06:20 UTC]

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.

[Comment 1 Alexander Berntsen (RETIRED) 2015-09-02 09:41:35 UTC]

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?

[Comment 2 Zac Medico 2015-09-02 16:20:46 UTC]

(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.

[Comment 3 Zac Medico 2015-09-02 16:28:08 UTC]

(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.

[Comment 4 Zac Medico 2015-09-02 18:35:55 UTC]

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

[Comment 5 Zac Medico 2015-10-12 16:43:58 UTC]

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.

[Comment 6 Zac Medico 2015-10-12 17:05:04 UTC]

(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.

[Comment 7 Zac Medico 2017-02-13 17:34:20 UTC]

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.

[Comment 8 Zac Medico 2017-03-05 22:08:37 UTC]

I'm thinking that the option will be called --update-any, will be enabled by default, and disabled by --update-any=n.

[Comment 9 Zac Medico 2017-03-13 05:51:34 UTC]

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

[Comment 10 Zac Medico 2017-04-26 21:31:42 UTC]

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.

[Comment 11 Sam James 2022-03-16 01:18:28 UTC]

*** Bug 802297 has been marked as a duplicate of this bug. ***