Re: [gentoo-dev] Addressing GLEP-62 itself

[Brian Harring]

On Wed, Sep 26, 2012 at 02:38:02PM -0300, Alexis Ballier wrote:
> On Wed, 26 Sep 2012 03:29:17 -0700
> Brian Harring <ferringb@×××××.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@×××××.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@g.o> 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.
>
> IUSE_RUNTIME is optional for PMs, why does the UI matter at all ?
> Also, the proposal doesn't assume flags are toggable at will, it assumes
> they are useflags and obey the same rules.

I truly hate claims like this; "it's optional, so who cares if it's 
whacky".  Think through the proposal; for it to work reliably, it's 
not optional.  Same issue I've been y'all over the head with, 
rendered/finalized vs raw/unfinalized deps being stored in the VDB.  

All managers have to write unfinalized if that proposal goes through, 
even if they don't support the optional toggling after the fact.  

As for the UI... arguing "but it's optional!" doesn't give a blank 
check for the UI angle.  What the plan, more colorization and a new 
char for emerge -vp?  Because we're kind of running out of chars 
there...

It's a simple enough request; one that wouldn't even need to be made 
if there was code backing this proposal; on a related note, hell yes 
I'm wary of having this dumped on manager authors heads and having to 
be told "sort out the mess/make it so".  So I'm asking y'all to at 
least put in an equivalent time investment doing a quick prototype.

This isn't an unreasonable request, and has been the norm for most 
gleps for a long while.


> > > > 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...
>
> It can't be stacked and it's not wise to do so; it is a simple bash
> variable like tons of others in eclasses:

It cannot be stacked because y'all are trying to shove this in as an 
optional; unlike it's brother IUSE, which stacks.

As for "ons of others that don't stack"; very few actually influence 
the package manager; ~14 roughly, minimally 5 of those stack (those 
that don't, basically aren't lists).


> """
> Package managers not implementing this GLEP will consider
> the ``IUSE_RUNTIME`` variable as an irrelevant bash variable
> """
> """
> 2. introduce additional ``IUSE_RUNTIME`` variable listing names of USE
>    flags related to optional runtime dependencies (without prefixes
>    related to IUSE defaults).
> """
>
> Treating bash variables as bash variables is rather the norm,
> stacking is the exception. As I understand it, your only objection here
> is that you want to see written 'IUSE_RUNTIME gets no special treatment'
> in the proposal ?

My objection is punting it to the council till it's actually nailed 
down/sane; having them mark it accepted means we're stuck w/ the 
results if it turns out to be shit at the implementation/UI level as a 
lot of us think it will be.

So yes, I want it actually finalized.  Bluntly; there's zero point 
having the council comment if it ain't finalized.

~harring