On Wed, Sep 26, 2012 at 07:25:11PM -0300, Alexis Ballier wrote: > On Wed, 26 Sep 2012 14:02:57 -0700 > Brian Harring <ferri...@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
