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 7A8FA139BC6 for ; Mon, 28 Sep 2015 01:20:50 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6389921C0C3; Mon, 28 Sep 2015 01:20:09 +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 52C8A21C044 for ; Mon, 28 Sep 2015 01:20:08 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZgN6q-00077N-E3 for gentoo-user@lists.gentoo.org; Mon, 28 Sep 2015 03:20:04 +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 ; Mon, 28 Sep 2015 03:20:04 +0200 Received: from martin by pc123.math.cas.cz with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 28 Sep 2015 03:20:04 +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: Mon, 28 Sep 2015 01:19:56 +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: fc29b72c-ef7b-49df-8811-b158c69762f1 X-Archives-Hash: af394495b7f0cd266459e9c69a8eb957 James wrote: > > Basically from my point of view, something like TUP [1] is needed so > that at dependency check time you only list files that need > attention (linking, loading, compiling etc) thus speeding up the > update processes for the Package Manager (portage). This is a misunderstanding (originally already from Michael). The issue is not at all about speed of portage - reading one or the other file takes the same amount of time. (And having a dependency graph of files would help concerning speed only in the very rare situation that no file involving your current package dependency tree does change.) The whole issue is only about the policy: If the dependency information of the installed package and of the current package differs - what is the "correct" information? For each choice, it is possible to give examples where the policy leads to a bad situation, so both, static deps as well as dynamic deps can break in certain situations. It is only a question which breakage you consider more severe and/or harder to recognize/fix by the user. Making more revbumps will increase the chance of no breakage - in case of static deps only for users who sync and update sufficiently frequently - of course at the cost of redundant recompiles. >> I guess at some point there were a bunch of devs who were messing with >> dependencies and not bothering to make revision bumps. This can cause >> users pain, so portage added a new option to ignore the cache and rescan >> every single relevant ebuild/eclass for sneaky dependency changes. This >> ensures that portage has the correct dependencies in its head while it's >> doing resolution, but is much slower. This is historically not correct. Dynamic deps had always been the only way portage treated dependencies - static deps have only been used as a fallback and (unfortunately) with the introduction of subslots. Once more: It is not about speed, but about: What *are* the "correct" dependencies? The ones referring to an historical tree which - especially if you did not update for a long time - might have almost nothing in common with the current tree (static deps), or the ones referring to current tree (dynamic deps)? With static deps, you will have a strange mixture of historical dependencies and current ones for the updates. With dynamic deps, the tree might not be appropriate for your installed packages. > There is no proper mechanism to accurately track all of these issue, > currently, or did I miss this point? There is no way to automatically decide correctly which of two differing informations should be used...