| Summary: | sys-apps/portage-3.0.30-r1: emerge only processes one set silently if multiple sets provided | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Sviatoslav @webknjaz Sydorenko #StandWithUkraine <svyatoslav> |
| Component: | Core - Interface (emerge) | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | gentoo |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
It's supposed to handle as many sets as you give it. So, if it doesn't appear to handle both sets, then something is strange is going on. Does reversing the order of the package set arguments makes a difference? Turns out you were right. PEBCAK. I wasn't attentive enough and somehow missed the package pulled in by `@preserved-rebuild` in the middle of long console output. Sorry for bothering you. |
After a world upgrade, I was reading the messages and the one from dev-lang/go-1.17.8 hinted to run `emerge @golang-rebuild`, plus emerge itself added a recommendation to run `emerge @preserved-rebuild` at the very end. Without thinking twice, I decided to combine these sets (because why not) and typed in: sudo emerge -1v @golang-rebuild @preserved-rebuild To my surprise, the output still contained the recommendation to `emerge @preserved-rebuild`. After looking into the suggested package reinstalled list, I realized that the package that needs to be rebuilt via `@preserved-rebuild` is not there. I tried using `@preserved-rebuild` and `@golang-rebuild` in the command separately and realized that with just `@preserved-rebuild` the expected dependency is pulled in while with both `@golang-rebuild @preserved-rebuild` only `@golang-rebuild`-requested packages get installed. I think, that there are a few problems here: 1) The manpage does not mention this corner case (docs issue) 2) The invocation just selects a single set and doesn't warn the user that the other one was ignored (UX) 3) It doesn't error out immediately, uses just the first set silently creating a false impression that the second one also influenced the invocation (UX) Reproducible: Always Actual Results: Just one set is installed and it's happening silently. Expected Results: I think that emerge should either error out in such a case + have this documented, or use all of the sets the user requested.