From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 5534813877A for ; Sun, 27 Jul 2014 21:26:35 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id ACF51E0B89; Sun, 27 Jul 2014 21:26:29 +0000 (UTC) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id B43D2E0B1C for ; Sun, 27 Jul 2014 21:26:28 +0000 (UTC) Received: by mail-vc0-f178.google.com with SMTP id la4so10217205vcb.9 for ; Sun, 27 Jul 2014 14:26:27 -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:cc:content-type:content-transfer-encoding; bh=5aZZcEfojPiwh78QNJshiZeWGPlfxxjvbJemf/SRqTo=; b=Pu3bbZLwwH/dk14jAz1cpevE55hEXplHnJ1VJD0atJnedvfLtYPFPujzrMrO3vD6C4 4p6VQSuNcVJvWlHCoo8xffd2dT8KXTW+4Ub++Op0IVMv/hbzC0fWvfpdBvSpp47hNszE 5+4IGRwmYHmc7TMDfqGMgAdRUNTBvmrRejzQ89ywIwrP5VvwEaqUuiY8Eyl9OkG9yhZc ivvNID7myQGaQfK/aV/eNRE27bdTJeFTIILFwkp7TVQDF4tCRRzY8+aPTqZftUeXMvkm fGn1/4B1BlMxhSnMKuWLqWzsYLZ2UhcddFv0LtGaPoR8TZzZbURTCpOSH0jlNX0hLrMr Nwew== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.53.9.234 with SMTP id dv10mr1050535vdd.56.1406496387886; Sun, 27 Jul 2014 14:26:27 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.52.8.229 with HTTP; Sun, 27 Jul 2014 14:26:27 -0700 (PDT) In-Reply-To: <20140727231701.68a980fc@pomiot.lan> References: <53CD6BED.10603@gentoo.org> <53CD8BBA.2010605@gentoo.org> <53D5072E.3030305@gentoo.org> <20140727222429.3febdefa@pomiot.lan> <20140727231701.68a980fc@pomiot.lan> Date: Sun, 27 Jul 2014 17:26:27 -0400 X-Google-Sender-Auth: _HQIL8-AyFxW5JP62Ck2tkUgQts Message-ID: Subject: Re: [gentoo-dev] don't rely on dynamic deps From: Rich Freeman To: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= Cc: gentoo-dev Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 8360fbb3-55bf-4d3d-a65a-49ae7d080cd3 X-Archives-Hash: e2b92432debbb0e3a9683370a312d084 On Sun, Jul 27, 2014 at 5:17 PM, Micha=C5=82 G=C3=B3rny = wrote: > Dnia 2014-07-27, o godz. 17:08:27 > Rich Freeman napisa=C5=82(a): >> >> I'd think that portage should update vdb as soon as it detects the >> dependency change. Then B would no longer depend on A in vdb. It >> shouldn't hold onto outdated information. > > You just introduced the opposite breakage -- when a dependency on C was > added, it ends up in vdb before C is installed. Now if C and current > version of A are removed before C gets installed, you end up having > broken dependency in vdb. > There is a possibility that you had the broken dependency before you even synced - you just didn't realize it yet. After all, if the dep was added only as the result of an actual on-disk change, there should have been a revbump. So, having a missing dep in vdb just makes vdb reflect reality. You can get a missing dep in vdb by unmerging a package without using depclean. An unmet dependency is still a dependency. > Plus, 'as soon' means you're making --pretend actually write something. > That's bad. This isn't all that different from package moves. I believe that modifies vdb as soon as it detects updates. There is the issue of syncing and then not updating and then having all the packages removed from the tree - you're then missing a package and have no easy way to install it. But, in that case you can put the necessary ebuilds into your overlay and then portage can make everything right. Rich