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 3D62813877A for ; Thu, 24 Jul 2014 22:33:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9DD06E0D4C; Thu, 24 Jul 2014 22:30:39 +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 D9E32E0C64 for ; Thu, 24 Jul 2014 22:30:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 71AC6340428 for ; Wed, 23 Jul 2014 08:53:25 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.157 X-Spam-Level: X-Spam-Status: No, score=-1.157 tagged_above=-999 required=5.5 tests=[AWL=-1.154, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1]) by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vurXqImCtdGs for ; Wed, 23 Jul 2014 08:53:19 +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 smtp.gentoo.org (Postfix) with ESMTPS id 5C3B234041C for ; Wed, 23 Jul 2014 08:53:18 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1X9sIU-0006JK-IH for gentoo-dev@gentoo.org; Wed, 23 Jul 2014 10:53:14 +0200 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 23 Jul 2014 10:53:14 +0200 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 23 Jul 2014 10:53:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: don't rely on dynamic deps Date: Wed, 23 Jul 2014 08:53:02 +0000 (UTC) Message-ID: References: <53CD6BED.10603@gentoo.org> <53CD8BBA.2010605@gentoo.org> <53CE11F9.8020700@gentoo.org> 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT d447f7c /m/p/portage/src/egit-src/pan2) X-Archives-Salt: b68e5172-0856-4db4-8e3d-0acb8bd920fe X-Archives-Hash: d8f2f0c1f61b37be167e66919ce1dcd6 Kent Fredric posted on Wed, 23 Jul 2014 06:44:57 +1200 as excerpted: > Ok, we can side step this discussion partially: > > Lets pretend for a moment dynamic deps get banned. > > People will still unconsciously make that mistake and things will still > break when they do. > > So we'll probably need a repoman check that is smart enough to know "X > is modified" and compare the DEPEND fields with the previous incarnation > prior to commit, and then at very least, warn people doing `repoman > full` that they've modified the dependencies, and that a -r1 bump is > thus highly recommended. > > And that check can be added *now* prior to banning/disabling dynamic > deps. > > And people who want to pay attention to that warning can start doing it > before policy dictates they must. Be aware that with eclasses generated deps taken into account, this /could/ trigger a LOT of arguably unnecessary revision bumps. Right now I'm trying emerge --dynamic-deps n --update --deep @world, and... Due to dynamic-deps and the (default) WANT_AUTOMAKE=LATEST (or whatever it is) stuff in the eclasses, I only have automake slots 1.11 and 1.14 installed here, but I still have well over 100 packages originally built with automake:1.13, that if I turn off dynamic-deps either need it pulled back in, or need to be rebuilt to pull in the automake:1.14 dep. I guess that's a variant of category 2 in the wiki list. It's a minor build-only dep change that doesn't need to be propagated immediately as the package is already installed, with dynamic-deps applying it immediately, but static-deps wouldn't apply it until a rebuild. As long as the older automake slot remains around to fill the dep, not a problem. Of course for users the fix is simple and what portage recommends, simply pull automake:1.13 back in (or don't let it be unmerged in the first place) and don't worry about it. I decided to go the rebuild route instead, here, and once I decided the number of rebuilds wasn't going to be easy to do with --tree giving me one at a time, I concocted a pipe involving bzgrep environment.bz2 to list them all so I could rebuild them in parallel, then did a wc -l on the output to get a count. But a repoman dynamic-deps checker might have flagged all those 125-ish package for revision-bump when automake:1.14 was introduced and thus became a dependency candidate. And I'm on ~arch, doing --deep --newuse @world updates routinely, with a not insignificant portion of my packages being live-ebuilds, so many of the package originally built with automake:1.13 have certainly been rebuilt by now, here. But I see a distinct possibility of an automake slot bump triggering thousands of rev-bumps, often to all available versions of a package at once, tree-wide. Meanwhile, one personal benefit to this discussion is that at least I understand now why merging a binpkg the other day pulled in some automake slot that depclean immediately wanted to remove. Binpkgs are static-deps and that one must have been built with that automake slot, but of course depclean was using dynamic-deps, so... Now I have a proper explanation for the behavior. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman