In a nutshell (this has lenghtly been discussed on the forums and it turned out that describing the proposal in the most reduced and compact fashion will more likely find resonance among long time gentoo users): emerge --update should only emit a notice/warning and not fail the update operation, if an ebuild for a newer version of that package exists, but the latest possible version due to keywords on dependencies is the currently installed one. In that case, emerge should proceed with updating the rest of the system (as it is usually the aim, when running --update) and only notify the user, rather than notifying him *and* failing. 1) It has been proven, that the proposed behaviour increases consistency, respectively rectifies existing semantic inconsistencies. For further information refer to the thread. It should just be noted here that it, in that regard, is undeniably an improvement to not call it an error, if the newest version cannot be updated to, unless that version is explicitly requested by a versioned atom. 2) There is no disadvantage, even for those who prefer the current inconsistent behaviour (possibly for tradition): They are still informed, as they have been before and can then unmask more packages as required, to allow the update. And those who don't want to unmask further unstable packages and want emerge to perform what "--update" implies, namely bringing the system to the latest *allowed* state, can update their system by that command as they like to. Reproducible: Always Steps to Reproduce: 1. Have the system in a state in which many packages need normal updating 2. One of those updatable packages should be in ~unstable and the updated version should newly depend on another package in ~unstable, which so far was not required to be ~unstable 3. Try to update Actual Results: You can't update, unless you also unmask the other package Expected Results: You should be able to update the other packages, which are not affected
> Steps to Reproduce: > 1. Have the system in a state in which many packages need normal updating > 2. One of those updatable packages should be in ~unstable and the updated > version should newly depend on another package in ~unstable, which so far was > not required to be ~unstable > 3. Try to update > Actual Results: > You can't update, unless you also unmask the other package It sounds like you're describing the --autounmask behavior which is enabled by default since portage-2.1.10. This behavior is only triggered by unsatisfied dependencies, which would cause emerge to abort even if --autounmask was disabled. So, I guess we can consider this as a duplicate of bug 328343?
(In reply to comment #1) > > Steps to Reproduce: > > 1. Have the system in a state in which many packages need normal updating > > 2. One of those updatable packages should be in ~unstable and the updated > > version should newly depend on another package in ~unstable, which so far was > > not required to be ~unstable > > 3. Try to update > > Actual Results: > > You can't update, unless you also unmask the other package > > It sounds like you're describing the --autounmask behavior which is enabled by > default since portage-2.1.10. This behavior is only triggered by unsatisfied > dependencies, which would cause emerge to abort even if --autounmask was > disabled. So, I guess we can consider this as a duplicate of bug 328343? I think yes. If I conclude otherwise I'll reopen this bug. Thank you. *** This bug has been marked as a duplicate of bug 328343 ***
