What you are requesting would require a complete redesign of the way Arch's package management works. Strict depends won't solve this. And if package A depends on openssl, it may break package B if you update package A.
Arch is designed in a way that it only works if you either update everything, or don't update at all.

Hello,

I see that this problem ahs severity low. However, I see this as a big issue. This type of errors breaks applications. People update a package which breajs packages that depend on it. For example now, I have this problem with ekiga on arch64 (is there a place to flag packages out-of-date for arch64?). Anyway, someone updated evolution-dataserver and now ekiga doesn't start anymore because of a dependency on libebook.so.5, which isn't there anymore.

A while ago, I had this problem also I think with apache, although I also maintained packages myself. I maintainted packages for apache 2.0.x, while in arch apache 2.2.x was in current I believe. The update to apache 2.2.x broke packages (also one in the repositories themselve I think: mod-python?) that depended on apache. Suddenly your webservice may not start anymore because of this problem. I'll repeat again. This was also because I maintainted packages outside of the repositories. But still, mod-python was broken and I had to maintain even more packages myself (apache 2.0.x, ...), atleast for a short period, because of the update.

My conclusion, the severity should atleast be bigger to my opinion. These problems occur. I'm not sure if the version-tag is good in this case, because a packager maybe doesn't know if a dependency will be broken in the next version of it ... It would be good if package-data could be updated without updating the package. So, if you pdate ssl to a newer version, you can check if all sofwtare that depends on it still works with the newer version and update the meta-data of the package to the newer version. Another possibility is that you say that softwarex needs atleast version a of a dependency y. If the dependency y is updated and a breaks because of that, that you signal that in some way (through meta-data?).

Greetings,

Michel

This isn't even a bug. Using the case of openssl: all packages requiring openssl are upgraded in the testing repo before pushing them to current. If you don't want half upgrades, don't use testing. If you want all packages upgraded, use -Syu. There's no problem. Making changes with regard to this will change some of the simplicity that makes Arch Arch.
I'd be glad to ship some script with pacman that does what you mention (it's very easy to script "upgrade this package and all packages that depend on it"), but I don't see this as a big issue at all. Broken packages are a maintenance issue, not a pacman issue. If a package is broken, complain to the maintainer.

I never used testing

But I agree, this ticket can be closed...