[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Addressing GLEP-62 itself
From:       Brian Harring <ferringb () gmail ! com>
Date:       2012-09-30 21:15:09
Message-ID: 20120930211509.GD2180 () localhost
[Download RAW message or body]

On Sat, Sep 29, 2012 at 11:55:22AM +0200, Micha?? G??rny wrote:
> On Wed, 26 Sep 2012 03:29:17 -0700
> Brian Harring <ferringb@gmail.com> wrote:
> 
> > 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 <ferringb@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 <axs@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.
> 
> What kind of addressing? The user interaction works like usual --
> portage lists a bunch of flags, some of them may have additional
> hammers or sickles to mean that they will not trigger the rebuild.
> Nothing more is required.
> 
> What is even more important, there is nothing new to learn
> for the user. In fact, he doesn't need anything new from UI. He will
> just set the flag like he did 10 years ago.

1) REQUIRED_USE interaction.  That's a rats nest, trust me on that 
one.  If your proposal is to just to have people tweak, get yelled at 
by the pm, tweak, etc, well, on behalf of users, thanks a lot.

2) While hard to comment since your 'updated' glep wasn't fully 
updated- now is self inconsistent (minimally, trace backwards 
compatibility; fix it in full next time)... you're not exactly 
covering how this will go; best I can figure, you just want to shove 
yet another coloring (great for color blind people) or syntax markup 
on emerge -pv style output, somehow indicating runtime toggable or 
not; this is getting picked at because that display already is a 
crapfest and overloaded.

3) You're ignoring cycles here; specifically suggested dep based 
cycles that influence the originating node, and how that is 
represented- this isn't counting representing during --tree mode what 
is brought in where/when because of it.

4) Finally, and more damningly, you're ignoring apps like porthole.  
You need to think long/hard about how *exactly* porthole is going to 
indicate to users what optionals are there- more importantly, what 
those optionals induce/require (that's where it truly gets ugly and 
your lack of dep resolver knowledge, and unwillingness to do a patch 
and learn the basics there become infuriating); || () or blockers w/in 
suggested alone are going to make things painful.


> > > > 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...
> 
> As others have said, we're not stacking it. Using it in eclasses
> is whacky and should be avoided. End of the story.

It's your proposal there boss.  That's a stupid decision, but as said, 
your proposal to run into the ground if you'd like.

However.  I suggest you actually document that in your proposal that 
it breaks from the stacking norm.  Also, drop the backwards 
compatibility claim at the bottom.  

It was bullshit before, the fact I keep having to picking at this 
means I'm going to start doing so in creative ways; thus I'll just 
quote an exchange from 'the carnival'- it's "pure beeship, beeship, 
not true, false, Beeship!" "oh... bullshit" "Oui!".  Quote wasn't a 
perfect fit, but I'm getting tired of having to use the plain 
'bullshit' response for your emails.


> > > > 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.
> 
> We talked about it, don't you remember?

Think you're being cracky there; the point I made there was that your 
proposal didn't address the need for unfinalized across all bulit 
deps- there was no discussion about that.


> That's why I have updated
> the spec and put the whole implementation details thing with special
> note what needs to be stored in metadata.

Not going to give you an inch on this shit anymore; Gleps are derived 
from PEPs; standard to include the cons of a proposal, in this case 
you actually need to quantify/document the perf hit (portage in 
particular) in there.

As for "updated to cover it"... meh.  I read that section; you're 
requirements of the PM imply we can always extract out the relevant 
bits from the original source trees.

Simple example,
encode? ( || ( x? ( blah ) y:=* ) )

with x being an IUSE_RUNTIME toggle.  Try extracting that.  It's a 
PITFA; partial rendering of all non IUSE_RUNTIME for the full tree, 
storing that tree in full, is what's required- that example 
demonstrates why thinking "just extract the parts" is cracked out 
(bluntly: moreso naive, as ciaran said, if you dick around w/ this 
level of the managers code, you're going to find that sort of thing 
intractable because of the rules of the syntax).


Finally, going to fold in a snippet from ciaran/you in a separate 
branch of this thread:

On Sat, Sep 29, 2012 at 08:43:14PM +0200, Micha?? G??rny wrote:
> On Sat, 29 Sep 2012 17:13:14 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > You've also still not provided any kind of reference implementation,
> > and your "reference implementation" section is still written with a
> > complete lack of awareness of how dependency resolution is actually
> > done.
>
> I'm sorry I haven't got time yet to write a package manager. I promise
> I will do it as soon as I have time to do so. Thank you for your
> patience.

Good news!

You don't have to write a PM from scratch- just modify portage to 
prototype it.  We realize how annoying it is to have your time wasted, 
thus a patch is enough.  Enjoy!


1) Don't be a tool.  Also, if you want to write a PM, I suggest you do 
so- the timbre of your proposals would likely shift towards sanity (or 
at least things would be quieter while you're off having at it with a 
windmill).
2) PMS requires portage support exist before a patch goes in; you've 
got to do that anyways if you actually think this is going anywhere.
3) The things the PM authors are beating you over the head with all 
map back to realities at the implementation level; if you'd get off 
your ass and do it rather than arguing, you'd be getting further with 
your proposal (or find it nonviable, and do a different proposal).


Honestly, your proposal doesn't feel like "optional deps"; it feels 
like you're just trying to shove in an efficiency hack to avoid 
rebuilds in certain cases, rather than designing a system for exposing 
suggested deps to people.  Efficiency hack doesn't involve a heavy 
UI angle, optiional/suggested deps do.

Either way, I'm done w/ this proposal; you come up w/ a prototype, 
I'll look, till then this is a waste of time.

Should the council/folk care, consider that a strong -1 on my part.
~harring

[prev in list] [next in list] [prev in thread] [next in thread]