On Sat, Jul 26, 2014 at 12:02 PM, Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote: > On Sat, 26 Jul 2014 15:59:58 +0000 (UTC) > Martin Vaeth <mar...@mvath.de> wrote: >> > And what if the match for :=3D is >> > incompatible with new dependency atom? Like when you replace >> > 'dev-foo/bar:=3D' with '>=3Ddev-foo/bar-2:=3D' but bar-1 is >> > installed. >> >> This is simple: The dependency is not satisfied. > > That isn't simple at all... It means you can't uninstall or upgrade the > package...
Why not? How is this any different from unmerging bar-1 back when bar-1 satisfied the dependency (using --unmerge which breaks reverse dependencies)? If you want to upgrade or re-install the package I would expect portage to pull in the missing dependency. I'd expect the next emerge -u world to do that as well, which it already does if you --unmerge a dependency). If there would be some unintended side-effect from doing things this way I'm all ears, but as long as you don't get into @system circular dependencies issues I'd expect portage to be able to install any packages that are missing after such a dependency change. Sure, until the missing dep is installed I'd expect a risk of breakage, but that is no different than what I'd expect if the package were modified without a bump and the package manager didn't attempt to support dynamic dependencies. Rich