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

[Brian Harring]

On Wed, Sep 26, 2012 at 07:25:11PM -0300, Alexis Ballier wrote:
> 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:
> > > 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 :)

Bullshit.  This is optional in the sense of embrace/extend 'optional'; 
if one PM takes up the new functionality, all have to switch to 
writing unfinalized deps to the VDB, and all have to switch to 
transfering that IUSE_RUNTIME crap to the VDB.

If they don't, whatever sole/crappy PM that runs w/ this proposal will 
wind up forcing rebuilds on any packages merged by the PM's that don't 
do this "optional" glep.

Thus rendering it nonoptional since it implicitly is reliant on all 
switching to the degrade *DEPEND writing that this proposal is reliant 
on.  The blame game becomes "well, you shouldn't use the PMs that 
don't do this *optional* thing".  There in is the implicit lie of that 
'optional' crap.

Claiming other wise is ignoring reality; I called it embrace/extend 
because this is exactly how that shit goes- sure it's optional, 'cept 
you're forced to support it (even partially) else the whole degrades 
and that PM winds up getting blackballed or fragmentation occuring.  
As far as I'm concerned, any PMS intended proposal must not pull the 
'should' or 'optional' crap; it has no place in a spec (spec's are 
supposed to be assertions after all).


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

Um... dude... This proposal is about adding suggested/optional deps so 
people can inspect/select/enable them per package.

You're asking "how is the UI relevant" in light of that.

Just saying; it's kind of core to this whole damn thing, else we're 
just trying to add an optimization hack; either one runs a strong risk 
of my next response including a joke about elderberries and hamsters. 
;)


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

This is one of the cases where "tough fucking luck" really/truly fits.

If it's doomed, consider why it's doomed.  I'm not requiring a 
prototype just because I'm a dick; I'm requiring a prototype because 
I fully expect since y'all won't listen to what people are telling 
you, trying to write the code will educate y'all to what we've been 
saying.   This is ignoring that prototypes are bsaically the norm for 
proposals of this sort (both PMS and gleps)... meaning it's the 
standard, and y'all are trying to get this proposal special cased.

Does it suck you can't just get what you want via writing a quick doc 
and arguing on an ml?  At times, yes.  If you believe it's worth it, 
you do the legwork.

If the folks backing this can't be bothered to write a freaking patch, 
well, I think that's a pretty strong vote of no-confidence on the 
backers part.


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

Also known as rubber stamp it.  And if it sucks, of course it's easy 
to roll that bad idea back?  Right?

If the idea was universally accepted and lacked issues, that may fly; 
that's not been the case.


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

Grr.  You're being daft if you think I'll back down just because of 
some word play and ignoring my points.

It *should* be stacked is my view; that matches it's sibling IUSE, and 
general behaviour for metadata lists.

However, that cannot be done if it's treated as 'optional'- that 
'optional' crap was attempted as a way to glue this onto existing 
EAPIs.  I'm pointing at the metadata issue since 1) that optional 
requirement results in the metadata key being ill fitting in 
comparison to IUSE, 2) it's easier to beat on that point then to have 
to argue w/ y'all as to the fact y'all are ignoring the implicit 
requirement of this proposal that IUSE_RUNTIME get added into the 
mainline caches (without it, more PM hacks would be required; 
additionally, the metadata cache angle is a further example of this 
being non-optional).


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

I reiterate; if a proposal needs the council to motivate people, that 
proposal is fucked- period.  If the backing author(s) can't be 
bothered to do the implementation, it's doubly so fucked.  Trace 
gentoo's history before arguing that one- there is a lot of examples 
already.

You can phrase it, argue it, whatever, all you want, but that's a fact 
of reality.  We've had lots of things get pushed up to the council and 
get 'approved', ie rubber stamped- and a lot of them went jack-all 
nowhere because approval != reality, nor does it even mean "of course 
someone will step up to do the work you refuse to do".  If you can't 
do the work yourself (or won't allocate the time to do so), or can't 
convince someone to do it on your behalf, the proposal is 
effectively dead already.

The Heinlein "There ain't no such thing as a free lunch" quote is dead 
on in this regard; you want it, do the work.  Involving the council 
just wastes their time, and our time via this argument continuing.


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

The implementation frankly isn't for me; y'all might manage something 
unexpected, but I've been laying out- much more so than the people 
pushing this- exactly what is going to be involved here, and the 
problems involved and why I've been -1'ing this bugger from day one..  
As said, y'all may surprise me, but I expect the implementation to
prove my points.

And... now the argument will be "well why should we waste our time 
doing it?".

A rather valid question I'd ask in that case is "if you respect my 
views enough that you'd *skip* doing the implementation if I said it 
was fucked, why were you freaking arguing and trying to railroad 
it through the council?"... just saying.

The reason to do the implementation is that if y'all think everyone 
else is wrong on this, do the legwork to prove them wrong, prove the 
idea works.

Arguing on the ML, needling people about "well this would've solved 
it" (see ciaran's labels behaviour from the last N years) aren't
productive.  Produce code, or shut up, basically; that's roughly the 
productive courses of action at this point.

I do want suggested/optional depends; I just don't want this mess 
jammed in since it doesn't solve it particularly well (and that's 
being generous in my word choice), and the associated cost isn't 
worth the gains in my view.  That simple.

Either way, if you'd like to keep trading blows, try pushing it to 
the council despite people bitching... have at it, albeit by yourself 
.  I've made my points, done with this thread (sparing people more 
emails).

~harring