Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal

[Brian Harring]

On Sat, Sep 29, 2012 at 05:05:09PM +0100, Ciaran McCreesh wrote:
> On Tue, 25 Sep 2012 15:46:14 -0700
> Brian Harring <ferringb@×××××.com> wrote:
> > Fun fact; peoples usage of labels in exherbo is thus:
> >
> > build+run:
> >   set of deps
> > run:
> >   set of deps/conditionals/etc
>
> That's largely because there are a lot of former Gentoo developers
> there who all said "oh, yeah, I forgot we could do it the other way"
> when this was pointed out...

I analyzed *all* exheres on git.exherbo.

To be crystal clear, these include your packages.

You yourself didn't use nested labels.  So either the author of labels 
'forgot' he could use it, or just didn't find the nesting actually 
useful.

Considering I've not found any examples where nesting /would/ be 
useful, I'm inclined to agree w/ y'alls usage- that nesting doesn't 
matter.

So... real world usage removes one of the core arguments of labels, 
leaving it just as "it's a new syntax/aesthetically more pleasing" in 
comparison to dep:build? ( blah ) form.

Not expecting you'll agree with that statement based on the facts of 
y'alls own repo... so if you're going to retort, bust out actual 
examples from eithe trees, where nesting would be preferable to the 
form people use now please; else just drop it (-your- own usage of 
labels disproves your claim; thus why I want actual examples now if 
that point will be debated any further).


> > > Specification in terms of rendering has a huge problem, though.
> > > Remembering the crazy rules Gentoo has for || ( flag? ( ) ), what
> > > does this do?
> > >
> > >     || ( dep:build? ( a ) dep:run? ( b ) )
> >
> > Honestly, I was waiting for you to bring this up :)
> >
> > You're conflating two different things here;
> > 1) someone being a dumb ass and writing what's effectively a || (
> > atom) block, just doing so in a manner w/out any reason to do so.
> >
> > 2) Your ongoing jihad against || (), specifically the occasionally
> > valid complaint that build/rdepend different means the resolver can
> > get stuck in certain pathways when slots are involved, abi, etc.
> >
> > Either way, in my proposal, I'm not going to single that out and try
> > blocking it.  The rendered version of it is still stable, albeit if
> > it's build/run it's unlikely to be desired if there is ABI involved
> > (for non ABI, specifically self-bootstrapping codebases, I suspect
> > someone could come up with a valid construct- sed has something
> > similar if memory serves).
>
> The rendered version ends up as ( a b ), in effect... It doesn't end up
> as || ( a (at build time) b (at runtime) ).

Er, I assume you left out some chars there.  The rendered version 
there isn't ( a b ); in old form it is:
DEPEND=|| ( a )
RDEPEND=|| ( b )

This is why I label it a stupid use of syntax, but not ultimately 
harmful.


> > Which is stupid, but syntactically correct.  Nor is this a new issue,
> > thus I don't particularly agree with your approach of trying to sink
> > the proposal via an orthogonal problem.
>
> No, you're introducing a new kind of weirdness for || ( ) here.

Na uh, you're the smelly face!

As I said, and via correcting your misrendering, this isn't 
introducing anything truly new here; people can/have done '|| ( a )'; 
it's a stupid construct, and for paludis it means it /does/ treat that 
as an OR block (for hte rest, we do the more obvious tree collapses 
during parsing, folding "a ( b )" down into "a b", same for "a || ( b 
)" into "a b" since they're the same thing).


> > Either way, via
> > http://dev.gentoo.org/~ferringb/unified-dependencies/labels/translated-to-use-deps.txt
> > , I think it's pretty clear labels in real world usage aren't
> > bringing anything to the tabel that we wouldn't have via my proposal;
> > that leaves labels as just a different syntax (perhaps aesthetically
> > more pleasing at first glance, but the label stacking bit via exheres
> > analysis is proven to be something people explicitly go out of their
> > way to protect against; meaning the aesthetics have a mental
> > model cost).
>
> It's not "go out of their way to protect against". It's "there's an
> easy way of making sure everything is composable". Your
> misappropriation of use flags doesn't have that.

Again, you're pulling a "na uh, you're the smelly face" counter 
argument.

Bluntly, you want something that is academically possible, but 
pragmatically/realistically unneeded- meaning the gains are basically 
not there, but the costs most definitely are.

Now, for exherbo were y'all lack actual versioned format (exheres-0 
has changed heavily since it's inception), and chucked everything and 
did it from scratch (right?  or do I need to do a copyright analysis 
in addition?)... the situation differs.  You can invent whatever 
syntax you want, since you're starting from scratch, changing the 
mental mode for parsing is fine.

We however are *not* starting from scratch.  This shifts what we'll 
accept for costs/gains ratio; frankly, the fact y'all don't make use 
of those claimed 'gains' makes me think y'all tried something and it 
turned out to be non-useful; it occurs in formats (ebuild format is 
littered w/ shit like that unfortunately).

Either way, this is gentoo, we're talking about the ebuild format; 
just the same as everyone shredded mgorny's ass for proposing we 
mangle atom syntax w/out gain, and proposal you push for the deptree 
changing, has to have significant gains for changing the existing 
form; aesthetics at a cost aren't enough.

~harring