You should be able to automatically pull in and install all those suggested packages when installing just the openoffice.org package by using the –with-recommends option mentioned above.

let me give you a practical example.
I started from CLI, and added openbox. I think a dock would be good, so I search and find several. I pick cairo and awn.
Aptitude tells me that there are 10 cairo pkgs. Which one do I install? cairo-dock seems a good guess. Do I also need cairo-core? And what about cairo-dock-plug-ins? And cairo-dock-data? This last one seems quite important too.
With awn things are a bit easier “only” 5 packages, but the concept is the same. Are we’re talking about a relatively tiny utility.
Sudo aptitude install openoffice shows 563 packages (!!!), just to give you a perspective.
I have no issue with setting things up so that users could cherry-pick their packages, but I think/assume, that the vast majority of users want “just” to install a dock, or Openoffice.
Why does this need to become a research study before being able to find out what to really install and what not?
And let’s not go into the dependencies, libraries …
Perhaps my many years of Windows have rewired my brain and I’m a lost cause BUt what’s wrong with having a “cairo-full-install” or a “openoffice-full-install” item (all with the same ‘post-fix’), or, if you want, the equivalent of a “setup” command?

As for the “nothing you cannot do”, AMEN!! You just have to configure it right.

That reminds me, I need to look up how to configure Midnight Commander to open graphics files with that framebuffer-based viewer…

So I guess that’s one way to find answers. But perhaps you’re also asking about how to know how to find answers? Forgive/ignore the following if that’s not what you’re after. To install something on an APT-based system, I guess you would have to at least be familiar with the fact that you’ll be using the apt-get command (or perhaps aptitude). With generally any command line program, you can always bring up its manual/help information with a call to man. Doing a ‘man apt-get’ gives a bunch of information about how to use apt-get, and also suggests looking into the apt-cache command (in the “See Also” section near the bottom of the man page). So one could/should then also do a ‘man apt-cache’ and would see how to use that. As for knowing that one should invoke man to begin with, well, running ‘help’ at the command line suggests doing exactly that. The output of help also recommends the ‘info’ command, which is another way to get helpful information. I think typing help at the command line is generally analogous to a help menu on whatever GUI application. (Of course, even with just text, you can pull off some semi-fancy ‘GUI-like’ functionality such as pull-down menus and whatnot, facilitated by libraries like ncurses–aptitude, for example, has such menus.)

So I would say the information you’re after is all there; it basically just needs to be read. One could certainly argue that reading through a bunch of man pages and help files is clumsy and not as intuitive as using a GUI and seeing various menu options and what-have-you. But then, that’s just a necessary difference between two interfaces. The command line (basically) only has text available, so that is just the way it works.

But maybe I’m not actually addressing your issue?

Back to Linux: my example on openbox is just that: an example. There are tons more. To install Firefox I could use sudo apt… firefox, but also sudo … firefox-3.6. If I pick Firefox, do I miss out on something? Which version will be installed? And, most important, how do I find out the answers to those questions?
I have no problem supporting separate packages for max flexibility, but the way it works today is just not efficient. Maybe my expectations are unreasonable, or maybe I am missing the point, or it’s simply that I don’t know enough about Linux to “see” what to do.
What amazes me is that so many people put so much effort in writing tools that are so handy, and then they “fail” to make those tools accessible to everybody in a simple/handy way.

I do follow your comparison with browsers and Flash plugins and it is somewhat relevant, but you see how practical it is to install a missing plugin? You get a clear message “Hey, you need this plugin to view this box” and a very clear action “Click here to install it”.
The equivalent would be that if a “firefox-read-me” or “firefox-main” or whatever, will tell me exactly what do I get if I install each of those packages, without having to scavenge through Wikis. Maybe I’m asking too much, but it seems a minimal effort compared to the building of the app itself.

Administering Linux is best done via CLI. Administering Windows is best done through the Control Panel, registry editor and a bewildering array of hidden gui panels. I have no idea how to administer OS X, but the point is that each OS has its BEST way, and on Linux that’s the command line.

We just need to get better at teaching people how to use it.

That matter settled, there are uses for everything. I can’t live without the console, but neither would I consider going console-only. It’s a deal of using the right tool for the job at hand. If your jobs don’t include console tasks, then you’re golden not using it, but telling the console to go and die in a corner just because YOU don’t need it is absurd.

And about aesthetics of webpages… aren’t we already past the point where people can force some layout on me when the only thing I’m interested in is the actual information on that very site?

I agree with one point, though: Raw output to stdout/stderror is a good thing. The problem is that sometimes the GUI tries to outsmart such output and “interprets” it in a wrong/insufficient way. Or maybe CLI and GUI versions aren’t compatible…