It will display descriptions of each use flag when passed the --longuse or -L flags. Written by Andrei Barbu & Sarah Fortune. Reproducible: Always
Created attachment 124710 [details, diff] Patch to emerge to add the flags
Created attachment 124711 [details, diff] Patch to emerge to add the flags
Created attachment 124713 [details, diff] Add the appropriate help string
Created attachment 124715 [details, diff] Patch to emerge to add the flags
Sorry for the deleted patches, had some issue with bugzilla. This might be useful, 'emerge -p -L emacs' now gives: These are the packages that would be merged, in order: Calculating dependencies ... done! [ebuild N ] app-editors/emacs-22.1 USE=" X Adds support for X11 Xaw3d Adds support of the 3d athena widget set alsa Adds support for media-libs/alsa-lib (Advanced Linux Sound Architecture) gif Adds GIF image support gtk Adds support for x11-libs/gtk+ (The GIMP Toolkit) jpeg Adds JPEG image support png Adds support for libpng (PNG images) spell Adds dictionary support tiff Adds support for the tiff image format xpm Adds support for XPM graphics format -gzip-el app-editors/emacs:Compress bundled Emacs Lisp source -hesiod app-editors/emacs:Enable support for hesiod -motif Adds motif support (x11-libs/openmotif x11-libs/lesstif) -sound app-editors/emacs:Enable sound -source Zip the sources and install them -toolkit-scroll-bars app-editors/emacs:Use the selected toolkit's scrollbars in preference to Emacs' own scrollbars"
I think this is too much extra output to include in the merge list display. It would probably be more appropriate as a separate option that's just for queries. Are you aware that equery already supports `equery uses <atom>`? I'm pretty satisfied with equery so I'm not sure about duplicating the functionality in emerge.
We're familiar with equery. The issue is that I must type in the atom into equery, which means copy and paste taking me more time. I think it's useful to see what flags mean. I'm not saying it should be on by default, it does cause quite a bit of output, but for many cases where one just wants to emerge one package (especially for newer users) it's really nice.
Uh, this is plain terribly cluttered, plus why don't you use euse, equery or whatever else that exists for that purpose?
Eh, half of my comment somehow vanished above, I'll try again. This would need to be colapsed at the bottom of emerge output with duplicate descriptions removed to be usable for anything but a single ebuild emerge - try this on something that requires many deps that are not installed and you'll see what I mean :). Or imply --pretend --nodeps (confusing and won't save you that much typing if you really mean to emerge it.)
I intentionally did not want it at the bottom. The idea is to make it simpler to figure out what each flag does. If it's at the bottom I still have to look up the flag in a list; not nearly as useful. That's fine, using them is an option; except that I now have to retype and it's a lot less convenient. This is a much simpler view. Why is it cluttered?
(In reply to comment #10) > If it's at the bottom I still have to look up the flag in a list; not nearly > as useful. I don't read you here; if you are interested in a single (or even couple of flags), then `euse -i flag1 (flag2 flag3)` is what you want. If you want them all, there's no need to look up anything? > Why is it cluttered? Well as said above, loads of needless duplicated info with global flags, try this on something else than a single ebuild. (Well, it's awfully verbose even with a single ebuild such as dev-lang/php but that's pretty rare one :P)
I'd rather wait until emerge has a saner codebase rather than adding yet another option that needs a rewrite later on.
It's a tiny change though, one that makes installing packages a much more streamlined operation for those who don't know what each use flag means. I don't think the eventual overhaul of portage is a reason not to add a small amount of code that makes it nicer to use. Since it's a useful feature now, that would be good later on as well, why not add it in now? You'll need to write it up in the new version of portage if you want it to exist at some point; meaning that there's no extra overhead, just the advantage of having it available all along.
(In reply to comment #13) > It's a tiny change though, one that makes installing packages a much more > streamlined operation for those who don't know what each use flag means. I > don't think the eventual overhaul of portage is a reason not to add a small > amount of code that makes it nicer to use. I wouldn't call a 6kb patch "tiny". > Since it's a useful feature now, that would be good later on as well, why not > add it in now? You'll need to write it up in the new version of portage if you > want it to exist at some point; meaning that there's no extra overhead, just > the advantage of having it available all along. The extra overhead is that we'd have to maintain it in the meantime (the work doesn't stop once a patch is applied).
