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 F27981391DB for ; Mon, 28 Jul 2014 07:00:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A2825E0DDA; Mon, 28 Jul 2014 07:00:10 +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 AB63BE0AA5 for ; Mon, 28 Jul 2014 07:00:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 415653400C0 for ; Mon, 28 Jul 2014 07:00:08 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.486 X-Spam-Level: X-Spam-Status: No, score=-1.486 tagged_above=-999 required=5.5 tests=[AWL=-0.816, RP_MATCHES_RCVD=-0.668, 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 nLLm3MOmDAbz for ; Mon, 28 Jul 2014 06:59:55 +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 EE85533FB3E for ; Mon, 28 Jul 2014 06:59:53 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XBeuU-0001Sy-Pq for gentoo-dev@gentoo.org; Mon, 28 Jul 2014 08:59:50 +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 ; Mon, 28 Jul 2014 08:59:50 +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 ; Mon, 28 Jul 2014 08:59:50 +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: Mon, 28 Jul 2014 06:59:38 +0000 (UTC) Message-ID: References: <53CD6BED.10603@gentoo.org> <53CD8BBA.2010605@gentoo.org> <53D5072E.3030305@gentoo.org> <53D51311.1070802@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: 843f1103-0d4c-4663-b199-cec97b886580 X-Archives-Hash: 2e32dddbcd14f1f555dc35d91c3a28a7 Paweł Hajdan, Jr. posted on Sun, 27 Jul 2014 16:56:17 +0200 as excerpted: >> One thing I would question in that table is "applied immediately (but >> can break hard when dynamic-deps stop working))." How can dynamically >> removing an "unused dependency" cause something to break, setting aside >> bugs in the package manager? If removing a dependency causes something >> to break, how can it be "unused?" > > Yeah, I was also wondering about this. I believe what is being discussed there is the following (as I understand it): 1) Foo incorrectly deps on bar, and doesn't actually use that dep for anything. Say it was a historical dep that upstream forgot to remove in the docs when they removed the dep, and the (gentoo) maintainer didn't detect it initially. 2) User installs foo with the incorrect dep, thus pulling in bar. At this point use has an unnecessary package installed but is otherwise fine, deps are wrongly pulling it in. 3) Foo maintainer detects the error (upstream removed the dep in the unreleased version and maintainer realizes it wasn't needed in the current version either) and removes the dep on bar, but since it was unused anyway and thus doesn't affect the package as installed (except in vardb), he takes advantage of dynamic-deps and no revbump is done. At this point, user has an unnecessary dep that portage has just been told about due to dynamic deps, and will unmerge it at the next depclean, but the user's dep-tree is still self-consistent and everything's fine. 4) Due to dynamic-deps, portage depcleans bar. Due to dynamic-deps, the user's dep-tree is still consistent and everything's fine. 5) Since nothing in the tree needs bar, it is removed. Due to dynamic-deps, the user's dep-tree is still consistent, because the in-/usr/portage foo.ebuild doesn't say anything about bar since #3. 6) Finally, foo is removed from tree. ** User isn't ready to get rid of foo yet, but user's dep-tree just blew up, because now portage falls back to the static vardb from original install, and that still says foo deps on bar, which is nowhere to be found! What's worse, the usual trick of digging the ebuild out of vardb and putting it in the user's overlay to shut portage up and let the user keep foo doesn't work, because the vardb ebuild has an unsatisfied dep. With the repeated caveat that this is as I understand it, if the above is clear along with the implications, you can stop reading here. The below simply expands on the above and its implications... The "breaks hard" bit can be applied for two reasons. First, exactly as I said above, the user's now SOL -- they had no warning things were going to break and now it's too late to do anything about it (unless they're advanced enough to figure out how to dig the last, corrected ebuild version out of a snapshot or the cvs attic, or to figure out that dep isn't actually needed on their own, and edit the ebuild they pulled out of vardb accordingly). Second, "breaks hard" can apply when a whole set of related packages were removed at once, all with the same bad dep. Consider for instance someone with kde-4.11 installed and how deeply dependent typical kde ebuilds tend to be on the kde eclasses. If the bad dep was in an eclass and applied to say 200+ kde packages the user may well have installed, then got corrected such that dynamic-deps killed the bad dep, then all of kde-4.11 was removed from the tree at once... A user may well find out they have 200+ broken deps at once! "Breaks hard", indeed! Now we look at the same set of triggering events with static deps. There are two cases, depending on whether the foo maintainer accounted for static deps and did a revision bump at step 3 or not: With a revision bump at step #3, at step #4, before the user can do the depclean, they'll have to do the revision upgrade. The aftermath of step #6 will then be hugely different as the vardb copy will have the bad dep removed as well. If the foo maintainer didn't do a revision bump, with static deps the user will have never depcleaned bar in step #4 as the vardb deps still say it's needed. So when foo is removed in step #6, again, no big deal. Sure the user had a useless dep installed the whole time, but when foo is removed from tree, fine, the user's dep-tree remains self-consistent and no blowup. And the user remains free to dig that ebuild out of vardb and install it in the overlay again, at least temporarily, to keep portage from yelling about it until the user has time to find an alternative to the package, or to upgrade to the new version (kde 4.12 or 4.13 in my mass-breakage example). Reinstalling may or may not be possible depending on how much the ebuild depended on eclasses and what had happened to them, but keeping the same thing installed at least temporarily should be fine. And the static-deps case of the user not upgrading in a timely manner and thus skipping step #4 entirely, resolves exactly as if the maintainer hadn't done a bump. Useless dep installed the whole time but no breakage. To complete the alternatives-tree, the no-window-update scenario with dynamic-deps would fall back to static/installed when the user updated after both packages were removed, and if an eclass wasn't involved, pulling the ebuilds out of vardb to stick in the overlay temporarily should still shut up portage, and the user could even rebuild from his overlay copy. But if an eclass was involved with that dep, however, pulling those ebuilds out of vardb and into the user overlay would trigger dynamic deps again, and what would happen then would depend on exactly how the eclass had changed. If the eclass had simply removed the bad dep then the effect would be extending the correction window, since with dynamic-deps that new information would now be used, allowing bar to be unmerged even with foo still merged. But if the eclasses had been updated to remove the old logic entirely (in the kde case, if the eclasses had their 4.11 logic removed already), then while portage would fall-back to the static deps as long as the ebuild wasn't available, as soon as it became available again, all hell would break loose as portage would see the ebuild in the overlay and try to use dynamic deps, breaking due to the eclasses no longer having the required support at all! Just in case someone missed the disclaimer above, that's as I understand it. I /think/ I get it, but I don't claim to be a PM/PMS expert and it's possible I have it wrong. -- 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