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 <ferri...@gmail.com> 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 <a...@gentoo.org> 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

Reply via email to