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 2AFF313881D for ; Sun, 27 Sep 2015 17:27:10 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A6BACE087A; Sun, 27 Sep 2015 17:26:56 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A182EE07F0 for ; Sun, 27 Sep 2015 17:26:55 +0000 (UTC) Received: from [192.168.1.100] (c-98-218-46-55.hsd1.md.comcast.net [98.218.46.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mjo) by smtp.gentoo.org (Postfix) with ESMTPSA id 58FD0340FC2 for ; Sun, 27 Sep 2015 17:26:53 +0000 (UTC) Subject: Re: [gentoo-user] dynamic deps, wtf are they exactly To: gentoo-user@lists.gentoo.org References: <56080616.5090406@gmail.com> From: Michael Orlitzky X-Enigmail-Draft-Status: N1110 Message-ID: <560826D7.7070307@gentoo.org> Date: Sun, 27 Sep 2015 13:26:47 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 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 In-Reply-To: <56080616.5090406@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: e0cb4a02-9196-4967-8397-0de135338aed X-Archives-Hash: 902283b0f0ccbedcd081340a2ed1060d On 09/27/2015 11:07 AM, Alan McKinnon wrote: > Does anyone here know what dynamic deps are exactly, how they work and > can describe them? > > There's lots of talk over on -dev about getting rid of them and the > closest description is from Ciaran, something like: > > "ancient shit that never worked right, involving phases of the moon" > "Dynamic dependencies" is a portage option. The abridged version is: whenever you go to install/update something, some of its dependencies may already exist on your machine. For example, if I go to install gimp right now, gtk is already there. With dynamic deps, portage will scan (that is, execute) all of the ebuilds for installed packages that could affect the dependency graph. If any of those ebuilds have changed, portage will use the new information rather than the info present when you originally installed the package. So if the gtk ebuild (that I installed a month ago) has been altered, portage will re-read it on the fly, ignoring what was in there a month ago. too short; didn't explain? When you install a package, its dependencies are recorded in the VDB: $ cat /var/db/pkg/app-editors/nano-2.3.6/RDEPEND >=sys-libs/ncurses-5.9-r1[unicode] sys-apps/file That's nice, because now if you want to install or update something else, portage doesn't have to re-execute every ebuild/eclass that could possibly affect the new thing -- it only has to check the VDB. But, if I'm the maintainer of nano and I change that ncurses dependency (let's say I drop it), then I have to make a revision bump on nano. Otherwise, the wrong dependency would stay recorded on everyone's system, and portage would happily use the recorded deps. 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. And then that mode was made default, which is where we are today. It doesn't sound that bad so far -- just a tradeoff between speed and the risk of using an incorrect cached dependency. Buuuuuuutttttt dynamic-deps mode doesn't always kick in. It interacts weirdly with subslots and other things. If portage can't find the same ebuild to scan, it will find one that "looks like it." If that doesn't work, it's supposed to fall back to the cache. Nobody has a flow chart of exactly how this works. It's all in the code and there's no specification. And, there are other package managers besides portage. When developers rely on dynamic deps and skip revision bumps, they're screwing users of paludis and pkgcore (and you, now that you have dynamic deps disabled). None of the magic is mentioned in the PMS, so you really can't rely on it and revbumps are needed regardless.