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 743B413881E for ; Tue, 29 Sep 2015 12:27:14 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CBA3721C007; Tue, 29 Sep 2015 12:27:04 +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 A4EDAE0804 for ; Tue, 29 Sep 2015 12:27:03 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Zgtzp-0005Bn-7V for gentoo-user@lists.gentoo.org; Tue, 29 Sep 2015 14:27:01 +0200 Received: from rrcs-71-40-157-251.se.biz.rr.com ([71.40.157.251]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 29 Sep 2015 14:27:01 +0200 Received: from wireless by rrcs-71-40-157-251.se.biz.rr.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 29 Sep 2015 14:27:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-user@lists.gentoo.org From: James Subject: [gentoo-user] Re: dynamic deps, wtf are they exactly Date: Tue, 29 Sep 2015 12:26:55 +0000 (UTC) Message-ID: References: <56080616.5090406@gmail.com> <56080B2A.3040709@gmail.com> 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 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 71.40.157.251 (Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 SeaMonkey/2.35) X-Archives-Salt: 28003de3-2e54-4688-8fc7-08b2c5f4238d X-Archives-Hash: 9883968a2a764b2c98e335ea17502a10 Mike Gilbert gentoo.org> writes: > Basically, yes. If [R]DEPEND in /var/db/pkg is different from the > values in the ebuilds in the tree, changed-deps will select it. > > Also, these two similar commands return different results (I have > > bdeps=y in DEFAULT_OPTS btw): > > > > emerge -uND --changed-deps=y world (51 packages) > > emerge changed-deps (11 packages) > > Do you know why those commands give different results? > > The smaller list is a strict subset of the longer one. > That difference is surprising; you would probably need to ask the > portage developers to get a real answer. I do not "own' the code underneath these options, nor would I waste my time on what is undoubtedly broken logic. Portage and associated tools do not have a complete description of the problem with the current VDB. A DAG is the best way to solve the problem of these portage anomalies. Or just rebuild @world and occasionally @system, and then cobble together a script that hopefully finds all the other installed codes and packages.... Still, cruft (some of the old files that should have been removed at some point) remains. I certainly and not saying this is an easy problem to solve; all distros suffer tremendously here. That's why many just 'reinstall' periodically. But without a robust implementation of a DAG or something similar, deep problems will remain unresolved and hopefully, not noticed. Many large data centers just 'reload' entire rows of racked systems too. These are big problems on clusters/clouds. The current approach is to build many 'customized frameworks' for different classes of problems, on top of poorly implemented distros with a collection of packages. That approach works well, if the packages are relegated to one complex language and scripts. Once a collection of codes, a package if you like, requires several complex programming languages to compile and execute, thus crossing framework boundaries, then the problems exponentiate, and it becomes an admin/security mess. I do believe that the current gentoo approach is going to be robustly application as a pristine solution for this gargantuan cluster problem; but a DAG sort of fundamental tooling is going to be minimally sufficient if stability is to be achieved. Clusters are already making their way to gentoo so these problem in only going to grow. Oddly enough, I feel like and uneducated admin in these matters. But, I do now have several major corps that want me to be a temporary consultant on cluster problems. We shall see. We shall see what's what. wwr, James