I think (and since the issue has come up several times in the forums, I'm not alone) that the --upgrade option of emerge does too much. IMO "emerge --upgrade package" should do only that: upgrade the named package if an upgrade is available, and only upgrade dependencies if the dependency upgrade is REQUIRED by the newer package. Instead, now, if package depends on X, for example, and you --upgrade package, an upgrade for X is automatically performed, even if package would function perfectly with the older version of X. I don't see any reason why --upgrade should do this. For automatic update of dependencies, we have --deep, don't we?
I don't have a personal opinion on this, but maybe the devs have decided so because otherwise `emerge --upgrade' would be the same as plain `emerge' (more precisely, would be the same as `emerge --noreplace'.
That is something I had not considered yet. But I still fail to see the use of automatically updating first-level (and first-level only!) dependencies. Especially because -U implies -u. I have several packages that I have chosen manually from ~x86. So, when updating, I have to use -U, to prevent automatic downgrading. But -U implies -u, so when I upgrade a small package that depends on a large package, I run the risk of updating that large package as well, even if the older version of the large package would be perfectly acceptable to the new small package (and to me!). I know that there are tricks you can use to prevent this (editing your world file manually, portage overlay dir, etc), but I think that a lot of these tricks would not be necessary if --upgrade did the same as --noreplace does now (or -U implied -n instead of -u). What am I missing here? The current behaviour of --update must have reasons that I have failed to see yet.
Use 49-r18 or the latest 2.0.50 series. /etc/portage/package.keywords
