| Summary: | portage: conflicts with missing argument should more clearly emphasise the missing package(s), not bury it in middle of list | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Mart Raudsepp <leio> |
| Component: | Core - Interface (emerge) | Assignee: | Portage team <dev-portage> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | Ordering issue example | ||
The clang deps do specify each target separately like this: llvm_targets_AArch64? ( ~sys-devel/llvm-17.0.3[llvm_targets_AArch64] ) Portage could group them by parent, and could possibly even merge multiple targets into a single atom, though merged atoms could be a little confusing since they differ from what the ebuild specified. So separately, maybe llvm.org.eclass could build the dep atom a bit differently. |
Created attachment 873814 [details] Ordering issue example When upgrading llvm along with other things, I missed lldb from outside @world upgrade run, but the output was very verbose and hard to spot the issue. It outputs issues between clang and llvm 19 times (where each takes several lines on a terminal) and the real issue is somewhere in the middle, buried in the spam. The spam happens due to all the different LLVM_TARGETS constraints that portage decides to list one by one instead of at once, which is a separate thing I understand is already on the radar or something separately. Sam thinks there are improvements possible here in terms of the ordering of this output that you can see attached.