Well, I'm a supporter of the monolithic ebuild method for KDE myself because it keeps --pretend so clean. Not to mention it makes unmasking masked packages much easier when wanting a full KDE installation. So when I found out that Gentoo wouldn't be offering monolithic ebuilds for KDE 4.0, I found myself upset with the decision (don't mind providing meta or individual ebuilds for those who want them, though). However, I did think of a way to make looking through a potential slew of ebuilds a bit easier, and it involves some changes to emerge. This might just make things easier for those both currently using or those soon to be forced using meta packages alike. Start Idea 1. When an ebuild has -meta at the end and that ebuild is called upon directly (emerge --pretend kde-meta), all packages would be listed as normal. However, when packages covered under the meta ebuild are called upon indirectly (emerge --pretend world), the output wouldn't show all of the packages, but instead just a listing for the meta ebuild with a number off to the side denoting how many packages will be handled. For example, output would look like "portage-path/package-meta (100)" instead of rattling off every single package that would be taken care of. 2. Then, a flag could be created to expand the contents of what's covered under the meta package, something like --metaexpand or whatever cool name you want to give it. Applying that alongside a --pretend would then show the contents of the affected listing(s). Might want to add a little disclaimer that emerge kde-meta shouldn't be re-emerged if all you're wanting to do is upgrade/downgrade/etc those particular packages. End Idea So, there you have it. So now, a user can have their emerge --pretend world (or similar) output look quite a bit cleaner. If they feel like looking at what's gonna happen to packages under a meta ebuild, then all they have to do is emerge --pretend that-meta. If it works for ya, cool. If not, I was tired when I wrote it. Just trying to think of some way to not have a mess to look at and thought that there might be something to this. At the very least, I hope it gets you devs talking about the subject of --pretend listing cleaning.
Check the dev ml for metapkg glep spb proposed, it would (basically) do this automatically without adding a special case '-meta' detection.
I don't really like special casing this at all, if it were to be done. Perhaps only list packages specified on the command line or those comprising a target if a target is specified?
I don't like a special case for this either. Perhaps it could be implemented as an alternative display option (akin to --tree) the summarizes dependencies rather than listing them all verbosely.
I guess I assumed at the time that you guys were gonna slap -meta at the end of all meta ebuilds. I agree that there probably shouldn't be special casing in this sense now that stuff like xorg 7.0 is going to be modular, etc. So, here's another idea. I agree with comment #2. Comment #3 sounds like my suggestion of a new option from comment #1, but in reverse (assuming that I understand it correctly). I'd still prefer that expansion of a meta listing be done manually instead of making a summary manual since keeping things tidy from the start and then having the option to see more seems nicer than having to look at an expanded list no matter what. I also don't know whether there should be a new option for expanding a meta list, or if emerge should list all of the packages under a meta by just using --tree. Also, for another idea, an ebuild could be considered meta by indicating that it is indeed a meta within the ebuild itself. That way, you'd eliminate having to append -meta to each meta ebuild while still being able to implement some of the ideas in comment #1. You could also have [ebuild M] indicate that you're dealing with a meta package.
I'd say to revisit this when we have general support for depgraph output plugins.
