From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-66943-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
	by finch.gentoo.org (Postfix) with ESMTP id 2AE3513877A
	for <garchives@archives.gentoo.org>; Sat, 26 Jul 2014 16:36:52 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id 3C3E7E0F6A;
	Sat, 26 Jul 2014 16:36:47 +0000 (UTC)
Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169])
	(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
	(No client certificate requested)
	by pigeon.gentoo.org (Postfix) with ESMTPS id 57218E0F23
	for <gentoo-dev@lists.gentoo.org>; Sat, 26 Jul 2014 16:36:46 +0000 (UTC)
Received: by mail-vc0-f169.google.com with SMTP id le20so342306vcb.0
        for <gentoo-dev@lists.gentoo.org>; Sat, 26 Jul 2014 09:36:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:sender:in-reply-to:references:date:message-id:subject
         :from:to:content-type;
        bh=R4ygO1S3eJcmTR1ssexzATzyAIOwIq1l+XsCjdxso1M=;
        b=h/EbRVKqK45nD9vp2TZZwmQwW5ZWSgvec0P9SuMKDTicb52Rqv4pEU3LkoiQgofceM
         saoCjdi8Lwv42mLb2T1W9LViwy5+PdDuXHqmZeEnZOuxKMeYBSEc5o0bZiZ/fbSArNNx
         lpTWGLDs8LGdW8xgRsb81SP4U5S6Tis4sujdDFo6dPS0RNe8SyZ37y+TPofU7T+JcRQ3
         MGeXUbGVD5xl2fsRJybOagBIgNg2MArmKNzJhDNrT/wK4P748UWneubT9mnzNiEDS8Q8
         ejq+6o/4C1eC5N/NxilBV/nd8jyMhFLbQwDykv30AmemCm1EdibB2t0tD97cYwmuZK/o
         z0pA==
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
X-Received: by 10.53.1.231 with SMTP id bj7mr1601063vdd.49.1406392605430; Sat,
 26 Jul 2014 09:36:45 -0700 (PDT)
Sender: freemanrich@gmail.com
Received: by 10.52.8.229 with HTTP; Sat, 26 Jul 2014 09:36:45 -0700 (PDT)
In-Reply-To: <20140726170256.01b75ce3@googlemail.com>
References: <53CD6BED.10603@gentoo.org>
	<53CD8BBA.2010605@gentoo.org>
	<slrnlt7dl6.9i1.martin@epidot.math.uni-rostock.de>
	<20140726163242.389162b6@pomiot.lan>
	<slrnlt7i7m.9i1.martin@epidot.math.uni-rostock.de>
	<20140726173506.1cf19e3b@pomiot.lan>
	<slrnlt7k3s.9i1.martin@epidot.math.uni-rostock.de>
	<20140726170256.01b75ce3@googlemail.com>
Date: Sat, 26 Jul 2014 12:36:45 -0400
X-Google-Sender-Auth: lZi1MYuKnatGncjMADPg4Z4SLfU
Message-ID: <CAGfcS_mbxJjdVY-tn1SH2nZuk3CN_QYBkcr2PEsQ1e5P3CQxgA@mail.gmail.com>
Subject: Re: [gentoo-dev] Re: don't rely on dynamic deps
From: Rich Freeman <rich0@gentoo.org>
To: gentoo-dev <gentoo-dev@lists.gentoo.org>
Content-Type: text/plain; charset=UTF-8
X-Archives-Salt: 1beea1bf-52fc-4984-a818-45b027e88a09
X-Archives-Hash: 14d48d6c14a93c5c672d32c5c0bd52bf

On Sat, Jul 26, 2014 at 12:02 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Sat, 26 Jul 2014 15:59:58 +0000 (UTC)
> Martin Vaeth <martin@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