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 DA50A13838B for ; Wed, 30 Sep 2015 09:41:42 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1CDEC21C051; Wed, 30 Sep 2015 09:41:29 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 0CDBCE086D for ; Wed, 30 Sep 2015 09:41:27 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZhDt6-0001q1-56 for gentoo-user@lists.gentoo.org; Wed, 30 Sep 2015 11:41:24 +0200 Received: from pc123.math.cas.cz ([147.231.88.123]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Sep 2015 11:41:24 +0200 Received: from martin by pc123.math.cas.cz with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Sep 2015 11:41:24 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-user@lists.gentoo.org From: Martin Vaeth Subject: [gentoo-user] Re: dynamic deps, wtf are they exactly Date: Wed, 30 Sep 2015 09:41:12 +0000 (UTC) Message-ID: References: <56080616.5090406@gmail.com> <560826D7.7070307@gentoo.org> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: pc123.math.cas.cz User-Agent: slrn/1.0.1 (Linux) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Archives-Salt: 5cf645e7-98a1-4f50-9ad9-c4c6f241acb9 X-Archives-Hash: 9bfc050d1f8c504f492bd147b993d5f8 James wrote: >[cr > DAG's All this can work only if you reflect the complete history in the DAG. Such approaches had been discussed and eliminated as unrealistic: You do not want to keep the history forever; the data will always grow and eventually be too much. Moreover, there can be overlays which might be added, perhaps eventually are abondened, replaced by other overlays, etc. It is not realistic to expect a complete history from them since you installed once from them. One must face the fact that at one stage you have the tree you installed and at another stage you have the current tree with possibly dramatic changes and no complete history of all changes. In the lack of such a history, simply there is information missing to decide the correct proceeding. You have to choose your poison which is either to take the old tree or the new tree as a basis (and to fill the gaps from the other tree). > Exactly. The current tools are insufficient The available information is *in principle* insufficient.