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@gmail.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
Addressing GLEP-62 itself
