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 75088138010 for ; Wed, 26 Sep 2012 10:32:09 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1C7EF21C077; Wed, 26 Sep 2012 10:31:21 +0000 (UTC) Received: from mail-da0-f53.google.com (mail-da0-f53.google.com [209.85.210.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 9434B21C04B for ; Wed, 26 Sep 2012 10:29:16 +0000 (UTC) Received: by dadg9 with SMTP id g9so124271dad.40 for ; Wed, 26 Sep 2012 03:29:16 -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=wwZyaXyXLt0kvISv1nlVgmEgBLEE7V8Pzzw4ssfxqek=; b=PZX7w+xrJCZxLArh7SoGOC/lSpsDo8MkIPXKn8FhKwY4d+H+Id0DzMMBR+JyD0Y/JC 1PCis8qE1DKIeSAI3pPMkH9nkLMTYVqhhVas9dy/9Q7qu9O40FWCUOvAQQAR4zvQr93G +xrNPCYJohRfJo8C5YO6CKZdikJgwKrtEnWrLiR+TniuSYJ6+JCIb2JCesJ0rmtiDeLy ccJJy5NzelYUVjpguav6qZ4ubRKuRKYuGY2hgosdOdVvZfzUKeDcmieYWLqe7mYyzRnc cZ2Uf5N1YWQ7xvi7dI9a9vcM2GuD1WwO6zIKONX50dJkJI8m9xgSErl/jUT921W9LFwS Jnlg== Received: by 10.66.83.8 with SMTP id m8mr120636pay.48.1348655355922; Wed, 26 Sep 2012 03:29:15 -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 h8sm1725206pay.0.2012.09.26.03.29.13 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 26 Sep 2012 03:29:15 -0700 (PDT) Received: by smtp.gmail.com:587 (sSMTP sendmail emulation); Wed, 26 Sep 2012 03:29:17 -0700 Date: Wed, 26 Sep 2012 03:29:17 -0700 From: Brian Harring To: Micha?? G??rny Cc: gentoo-dev@lists.gentoo.org, axs@gentoo.org Subject: Re: [gentoo-dev] Addressing GLEP-62 itself Message-ID: <20120926102917.GA14175@localhost> References: <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> <20120925195439.GA26094@localhost> <20120926080244.2733f52d@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: <20120926080244.2733f52d@pomiocik.lan> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: 9c726060-e8c0-40c3-b6d5-af1ec04b6ece X-Archives-Hash: 28343a2b11da796836bccff69408d389 On Wed, Sep 26, 2012 at 08:02:44AM +0200, Micha?? G??rny wrote: > On Tue, 25 Sep 2012 12:54:39 -0700 > Brian Harring wrote: > > > 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. ^^^ This point still needs addressing. > > 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. > > The proposal didn't cover eclasses at all. Is there a need to do so or > are we chasing some kind of perfection based on filling all unused > slots? Eclass stacking here matters; if it's stacked, it means ebuilds have to use out of bound (ie, other vars) to tell the eclass when it shouldn't mark a flag as runtime toggable. If it's not stacked by the pm, then they have to manually stack; that differs from the norm and makes it easier to screwup; however; does allow for them to filter, albeit a slight pain in the ass doing so. There's a choice there, and the answer matters, so yes, you should actually have a complete glep before trying to shove it up to the council and extract a vote out of them. Lest the intention is to just have them kick it back to the curb... > > 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. > > There's a footnote there, saying: > > The package manager has to ensure that all relevant information is > stored in the installed package metadata. Frankly I don't fully buy that you were aware of this issue from the start of the proposal; the wording partially covers it however. Ddoesn't call it out, but via tha req it dumps it on the package manager developers heads to sort it- which already is the case. Binpkgs minimally weren't addressed which is why I still don't think this was actually spotted up front. Were it, the performance impact should've been mentioned, and quantified; con's are part of a normal glep. Meaning.. wait for it... writing a prototype is required to get those stats. ;) > > > > Based on the above I do expect the reference implementation > > > > would alsoneed 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. > > > > > > > > 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. > > What are you talking about? As far as I can see, we are talking here > about *full rebuild*. Added the full quote above. Read prior to the corollary; that's proposing transferance of *depend from live tree to vdb; that's not common- portage alone does that, and it's got faults that make it unlikely you'll convince others to replicate that behaviour. ~harring