As said in the summary. Doing this would allow a user to quickly see what xcursors ebuilds were available from the tree. This currently effects: blueglass-xcursors, golden-xcursors, and silver-xcursors. Reproducible: Always Steps to Reproduce: 1. 2. 3.
emerge -s xcursors?
Yes, this is true. But sometimes its just easier, when you're close by, path-speaking, to peak in the dir and see rather than take the x mins off to wait for a search, which in this case would yield 3 pkgs. Still it remains, that presorting data is always better in the long run. This is an example of disorganization. Also, look at other pkgs, desklets aren't named: goodweather-desklet or calendar-desklet, that wouldn't make sense and that is why they are actually the other way around. Same with gtk themes. Say I want the gtk2 theme, lighthouseblue. Under the current scheme and using my memory, I know I can cd into /usr/portage/x11-themes/gtk-eng.. hit tab and see what's available. This is much quicker if I only know the first part of what gtk themes syntax is. Say I only remember gtk, then a quick cd into the dir, type gtk, and use completion. If the pkg or types of pkgs are potentially more diverse in their naming and potentially spread across the tree, then, yes a search utility is probably going to be more time efficent. But, at this time search is far too slow for all uses, imho, and besides, would you name your mp3s: title-artist-album? Probably not. Imagine, on a simple list, trying to find the artist that did some album that had that cool track. If it was organized, you could find it by just scrolling to the artist, it might just be close by, choose the album, then track. But, in this example, your always forced to do a search and if the search utils no good or takes too long... well...
Sorry about the unending sentence.
i'm sorry, but i agree with seemant... it places too much stress on the rsync mirrors and cvs.g.o to make trivial and largly useless changes like this... if emerge -s is too much work, go to packages.g.o
