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

[Alexis Ballier]

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.

> > > 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:
"""
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 ?

A.