Summary: | emerge -pqv should display USE flags | ||
---|---|---|---|
Product: | Portage Development | Reporter: | David Watzke <david> |
Component: | Core - Interface (emerge) | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | Keywords: | InVCS |
Priority: | High | ||
Version: | 2.1 | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 136244 | ||
Attachments: | Patch against emerge-2.1.1_pre4-r2 |
Description
David Watzke
2006-04-02 21:53:46 UTC
I think --quiet overrides verbose. And that's good or bad? I don't know, but I think that this would be better. Sure, only if it's possible and if it won't collide with something other... Well in the code we have four 'states'. Verbose is on/Quiet is on Verbose is off/Quiet is on Verbose is on/Quiet is off Verbose is off/Quiet is off There are pieces of "verbose" output that are not...'guarded' by a quiet. Meaning that in some cases emerge -vq will print verbose info even if quiet is specified. However *most* verbose outputs are guarded by a quiet, meaning if quiet is specified portage will ignore verbose completely; this is what is happening in this case. I could see the case for two things: a) Make command line order matter, if it's -qv then verbose turns quiet off, or vice versa. b) make one always over-ride the other. I'm all for a) personally. That way even if a script is overly verbose/quiet I can still affect the outcome without editing the script itself, just by passing certain parameters to it. b) just means that once I've set one I can't 'unset' it. Alec, I dont think getopt ordering should matter in the slightest or be made to. I'm thinking more along the lines that -qpv should display USE= flags but more in the classic style (so they can be parsed easy) + [ebuild R ] sys-apps/less-394 unicode And none of those expaned other variables like ELIBC... LANG.. Personally I'm against that only because I dislike a ton of display logic....How many different levels do we need, although that is more of an implementational detail ( how do you reduce display complexity ) as opposed to why or why we shouldn't have it. Hmm... I like solar's idea :) How about a numeric verbosity level where -v increases it and -q decreases it? SO -qv would neutralize each other (unless one of them is repeated)? Not sure how well that would work with the current CLI parser though. Created attachment 93494 [details, diff]
Patch against emerge-2.1.1_pre4-r2
Patch to fix this!
thanks this patch seems to work perfectly. InSVN revision 4159 This has been released in 2.1.1_pre4-r4. |