Say you have a package Foo that relies on package Bar.
Initially Foo v1.0.0 relied on Bar v1.0.0.
Bar updated to v2.0.0.
You now update the dependencies of Foo so it now requires Bar v2.0.0.
Since this upgrade of Bar does not break, add, or fix any feature in Foo, which part in the semantic versioning of Foo should you update to reflect this change?
Note: In case you're wondering why do I even have to update Bar to v2.0.0 if it won't change anything in Foo -- if other packages in your app also require Bar but at v2.0.0, it will conflict if Foo only requires Bar at 1.0.0. AFAIK this is the behavior in PHP Composer.
Unless your package is a meta-package built to provide the package Foo, technically, it wouldn't require a change of version.
If you declare your dependency using version ranges (because from the point of view of your package you can depend on any version irrespectively), so it becomes:
"foo/foo": "^1.0 || ^2.0"
The public API of you package hasn't changed at all. Or at least it shouldn't. The internals of your package are not the business of your package consumers, if you are correctly encapsulating your dependencies.
You are not adding or changing features, you are not breaking backwards compatibility. At most it's a patch to redeclare your dependencies, nothing more.
I'd be fine bumping Foo to 1.0.1, to make the change in dependency declaration explicit, but nothing else. (Also, users of 1.0.0 and users of 1.0.1 would be effectively installing different libraries; so not changing the version number at all would be misleading, IMO; and not changing the version wouldn't allow package consumers to get the version with update Bar, if they needed it).
Still, it's a matter subject to a fair degree of opinion. You may want to read this lengthy discussion, for example.