Description: ------------ "pear upgrade" unnecessarily upgrades dependencies of the package being upgraded. e.g. assume that the following is installed: A-1.0.0 (depends on B-1.0.0) B-1.0.0 The channel server has: A-1.0.1 (depends on B-1.0.0) B-1.0.1 "pear upgrade A" will also upgrade B to v1.0.1, without warning. This is unexpected (the user didn't ask to upgrade B) and unnecessary (there is no dependency on the newer version). It would be better just to warn that a new version of B is available.

In the example cited the dependency has a minimum version, not a maximum or specific version. Packages CAN specify specific versions as well as maximum versions, and the installer will respect that. There should be no risk of upgrading the dependencies and this allows bugfixes and security fixes to get out.

I have to agree with Brett here. If you run "pear upgrade A" then it will upgrade the deps and I see no problems with that. If I recall correctly, that's how yum behaves as well; Tho I might be wrong. Perhaps I am not understanding the implication here; Tim if you could explain why a warning instead of upgrading within the preferred_state is a better approach?

It's as simple as minimising risk and the "principle of least surprise". Although it SHOULD be safe to upgrade dependent packages within the same preferred_state, unfortunately developers sometimes make mistakes, and PEAR has bugs like #13427. The problem is that when installing one minor upgrade to a package can result in a huge chain of dependencies being upgraded, this: a) increases the risk of a regression in one of the many dependencies being upgraded. If I *know* that I only want one particular bugfix (and any *necessary* dependencies) then PEAR pulling in a load of other unnecessary stuff makes life more difficult for zero benefit (see also (e) below). b) makes it hard to find such a regression (because of a whole load of things being pulled in at once) c) makes it harder to test a single upgrade in isolation i.e. to test the bugfix in "A" knowing that I'm testing *only* that change. (And "--nodeps" isn't an option, because that stops even necessary upgrades being done.) d) can, unfortunately, result in bad versions of packages that violate the min/max criteria in the dependency chain being pulled in - see bug #13427 which is a genuine PEAR bug but unfortunately marked as "won't fix" e) does not have any benefit - because if it worked the way I'm proposing, I can always do an "upgrade-all" to pull in the rest of the random updates once I'd tested my (intended) upgrade and was happy that it worked. That way gives me options; PEAR making an "upgrade" (almost) equivalent to "upgrade-all" conflates two options. I haven't explicitly tested yum for this, but I don't *think* it would behave like this.