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

Reply via email to