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

[Alexis Ballier]

On Wed, 26 Sep 2012 14:02:57 -0700
Brian Harring <ferringb@×××××.com> wrote:

> 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.

Why? _Current_ PMs will rebuild the package. The point of this is just
to give them a hint that they do not need to rebuild it. We already
have an implementation actually: one that ignores the hint :)

> 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...

How is this relevant ?

> 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.

I guess people do not want to invest time in writing code for something
doomed. The original request was just to have it 'accepted' so that an
implementation can start. If the implementation is good then make it
final, otherwise amend or reject the glep. This isn't unreasonable
either.

> > > > > 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).

So it's not stacked, nothing else to discuss here :)

> > """
> > 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.

Then the proposal itself should be discussed, not the implementation
details: chars for emerge -pv are irrelevant; you pointed the raw dep
issue in the VDB, that's good, but never said anything as of why they
can't additionally be stored, making this a non-issue for the
_proposal_ acceptation.

Anyway, without implementation I expect the council to just give a vote
of opinion, showing support or non-support to the proposal; the
proposal will be final only once the council will be happy with
portage's implementation. And I agree, the council doesn't need to be
involved to start the implementation, but knowing this proposal has
supporters will motivate people to do the implementation, vs. not even
being sure the idea itself will get some support.

Would you support the proposal if you are happy with its
implementation ?

A.