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 A8128138010 for ; Tue, 25 Sep 2012 19:55:43 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AF5F321C0EF; Tue, 25 Sep 2012 19:55:22 +0000 (UTC) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 9959D21C0BB for ; Tue, 25 Sep 2012 19:54:39 +0000 (UTC) Received: by pbcwz12 with SMTP id wz12so697337pbc.40 for ; Tue, 25 Sep 2012 12:54:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=EEQZsIsT9XCRxVlGwFZwgNNL29W4mDRr0jGwQpRCkts=; b=AYxirDRn4eRR7wfxm+LE9LgxvWzIYo4TxLMiiPe96HcpCUFEridxlEIrn8nP6FJ9mT 3v2RLrNvYMwKI+q0dHmVJrKDGcwsAp7AUPW3piOTHU2lE3l/SvP7n4RPJ+E8MvIZ48hF Nf7zzktVbn47Qq6V1lqXdeO2Q0skoUp74FKpeUELV+Rw4a45SScqjwbsVHBT4BXomEQb lORP+LKdNgUZCbQaZf4rQzOFmA/nhR46f/F02QVbVciCPM3QyPzKRWA6PFDY5pcjqWGb Oi3ZwypllW1ownyLX2LuqWu0y0iFHAhnT23VtQAQkFy2HZYQkokHLTqAhoBv1HyHYJND 082A== Received: by 10.66.75.132 with SMTP id c4mr21815934paw.2.1348602878902; Tue, 25 Sep 2012 12:54:38 -0700 (PDT) Received: from smtp.gmail.com:587 (74-95-192-101-SFBA.hfc.comcastbusiness.net. [74.95.192.101]) by mx.google.com with ESMTPS id uu10sm786185pbc.2.2012.09.25.12.54.36 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Sep 2012 12:54:37 -0700 (PDT) Received: by smtp.gmail.com:587 (sSMTP sendmail emulation); Tue, 25 Sep 2012 12:54:39 -0700 Date: Tue, 25 Sep 2012 12:54:39 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Cc: axs@gentoo.org Subject: Re: [gentoo-dev] Addressing GLEP-62 itself Message-ID: <20120925195439.GA26094@localhost> References: <5061C817.2000502@gentoo.org> <20120925161056.33564020@googlemail.com> <20120925124300.54b2900c@gentoo.org> <20120925170007.1f2c2372@googlemail.com> <5061D989.2080604@gentoo.org> <20120925172557.4b3175a6@googlemail.com> <5061DE72.6090700@gentoo.org> <5061F1F8.70904@gentoo.org> <5061FC45.5020502@gentoo.org> <20120925205807.5e4def52@pomiocik.lan> 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=us-ascii Content-Disposition: inline In-Reply-To: <20120925205807.5e4def52@pomiocik.lan> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: 6a37a105-81bb-4f21-a1bd-0f32012232e9 X-Archives-Hash: d256dbd3d287862fbc919fbaf2fd190b On Tue, Sep 25, 2012 at 08:58:07PM +0200, Micha?? G??rny wrote: > On Tue, 25 Sep 2012 14:47:33 -0400 > Ian Stakenvicius wrote: > > > Based on the above I do expect the reference implementation would also > > need to change. I expect, for instance, that the PM's > > metadata-handling would need to occur as normal even though none of > > the package's phase functions would run, that is, *DEPEND > > (realistically RDEPEND as that should be the only one affected here, > > maybe PDEPEND too) and USE/PKGUSE would get updated. Since portage > > would not be re-emerging the package from the tree the original ebuild > > would remain. > > Yes, unless I'm missing something that's the intent. I will re-read > and update the GLEP a bit sometime this week. There's a fairly strong user interaction component here, along w/ potential nastyness for ebuilds (the proposal assume that a flag will be toggable in all cases within an ebuild if IUSE_RUNTIME specified; I guarantee instances where that fails can be found in the tree if a basic audit was done). Additionally, this *is* useless if it's done in a form the UI an't display/handle; Ciaran may bitch about REQUIRED_USE's UI (which I knew going in was going to be problematic, just to be clear), but he's right on that front. Additionally, this needs to be thought out how it'll interact with eclasses; what stacking, etc. It doesn't cover the basics there to say the least. Pretty much, this needs an implementation, partial conversion of the tree to demonstrate it. Just to prove that fricking point; if you had tried implementing this, a full investigation of what's involved alone, you'd have spotted that the core of the proposal is based on a wrong assumption. Portage doesn't write unfinalized DEPEND/RDEPEND/PDEPEND to the VDB. Literally, USE=-x RDEPEND="x? ( dev-util/diffball )", the RDEPEND in the vdb is going to be "". The retort is "meh, that's minor"; the fact this was missed doesn't inspire confidence; further, aside from the fact that writing finalized deps to the VDB ie, an accurate form of the deps- they're locked at that point, a smart PM can take advantage of that to avoid reading USE/IUSE till it's needed. This has measurable speed impact; if in doubt, rebuild a tree without it- that little trick I came up with first in pkgcore and it works on two fronts; 1) parsing is quicker, less nodes/smaller tree, 2) a smart PM can lazy load the USE/IUSE for performance gain. This is why portage/pkgcore were intentionally modified to do this; paludis may do it, haven't looked. My views, if the council is sane they'll slap it back down stating "prove it's a viable solution"; regardless of my views of the proposal (that it's the wrong way to solve it), it's not ready for an actual vote since approving it without actually verifying it could work makes things fucktons worse. > > I expect, as a corollary to this, that a rebuild would be necessary if > > (on-disk-IUSE_RUNTIME xor in-ebuild-IUSE_RUNTIME) was non-empty > > (--newuse) or resulted in any flags that are in USE > > (--reinstall=changed-use). IMO this would be necessary to ensure the > > local ebuild copy and all related metadata for it gets updated in vdb. > > I think that's a common package manager logic and it's out of scope > of the GLEP. Portage doesn't do physical updates last I saw- if it did, well, that's fairly dangerous. Only thing stored in the VDB is the ebuild and the environment dump, and the environment dump is what's ran from. You cannot sanely pick part the dump and try to intermix current ebuilds; rephrasing, I'll kick in the head anyone who tries that. We used to do that shit; it broke, frequently. Env saving took a long time to get landed across the board- doing what you're proposing the PM should do breaks those guarantess and is a step back on that front alone. Basically, not happening, if it is, a series of bugs need filing. What portage does is that if it sees an ebuild in the tree that matches, it uses the deps from the tree; that's wholy different from what you think is happening in the vdb. Additionally, portage is the only PM that does this; the rest of the PMs treat the vdb ebuild as a constant- without extreme care, or some form of insane deptree comparison, you can't just swap in what a new ebuild has and expect it to work in all cases. ~harring