Summary: | sys-apps/portage: include app-alternatives/* USE flags in emerge --info | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Michał Górny <mgorny> |
Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | arsen, sam, ulm |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Michał Górny
![]() ![]() ![]() ![]() I am undecided whether these should be included. emerge --info output is already too long for my taste. If we're going to include them, then the second option looks more future-proof to me. It needs to contain enough information to be useful in determining likely causes of a bug. (In reply to Ulrich Müller from comment #1) > I am undecided whether these should be included. emerge --info output is > already too long for my taste. > > If we're going to include them, then the second option looks more > future-proof to me. In case ``emerge --info'' isn't meant to serve as a tool to quickly gather bug report information, an ``emerge --bugreport'' which contains this info and more seems appropriate, though I'm not sure that's the case. |