pacman -Ss gnome # searches for gnome
pacman -S gnome # installs gnome pacman -Ss gnome # searches for gnome
pacman -S gnome # installs gnomeIn the particular case of pacman, I really like the design of the arguments, in particular the top level ones. -S is for syncing, -R is for removing, and -Q is for querying and so on. Nice!
Package managers are funny beasts. They're like children, when someone rips the flaws of one, the community comes rallying to its defense.
Having said that, I've personally always hated Zypper.
Nevertheless, you may add some alias to change the behavior if it's annoying you.
Pacman is especially confusing since -S actually means the sync mode. Which doesn't really fit with the idea of installing a package. Also, why do you use sync mode to install a package, but have a special remove (-R) mode to remove a package? Shouldn't there be a -I to install?
To take it further, standard use cases for a package manager should be install, upgrade, search and remove with standard arguments -i/--install, -u/--upgrade, -s/--search, -r/--remove.
It seems that most of the package managers get this wrong. For apt-get what's the difference to update, upgrade and dist-upgrade? For yum why is there both an update and an upgrade and why is there a special groupinstall? I know the answer to these questions, but it's confusing until you wrap your head around it.
The idea is that you are synchronizing your copy of the local package (which is currently empty/nonexistant) with the remote copy. It's also the same command you use to update that package. So,
pacman -S foo
will upgrade foo if it exists locally, and find and install the most recent version of foo if it does not.
Once you get used to it, the command-line switches in pacman actually address your second concern (the one with apt/yum). In pacman, everything is built on top of a very simple database model - it just so happens that that simple database model is also powerful enough to serve a range of complex functions.