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

[Brian Harring <ferringb@gmail.com>]

On Sun, Sep 30, 2012 at 09:30:18PM +0100, Ciaran McCreesh wrote:
> On Sun, 30 Sep 2012 13:14:53 -0700
> Brian Harring <ferringb@gmail.com> wrote:
> > > 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.
> 
> That's a rather disingenuous claim, considering how none of the
> packages I maintain have any non-trivial dependencies... You could
> equally well say that every single package I maintain makes use of
> nested labels in every single place where they're relevant.

Admittedly, that was a punch nearing the belt or a bit below; that 
said it's not disenguous.

Reality is, our current form can handle deps generally fine- what you 
label as trivial is the vast majority- I argue effectively all.

And I intentionally gave you a way to disprove that; find real world 
dependency examples to disprove it.


> > 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).
> 
> It's not just that it's more aesthetically pleasing. There are two
> arguments favouring labels over use abuse.
> 
> The first is that it doesn't have perverse behaviour associated with it
> like your misappropriation of use conditionals does. If you put labels
> deep in a tree, it's well defined. If you put your conditionals
> anywhere except the top level, crazy stuff happens.

This statement of yours however is fairly disenguous; label behaviour 
when nested suffers the same mental parsing oddity (wait, we're in 
build context, and this is test?  Wtf happens there?).  With 'use 
abuse' however, the situation is clear:

dep:build,run? ( x? ( dep:test? ( blah ) foon ) monkeys )

Means that 'blah' target doesn't show up.  Which is the *same* as what 
happens if someone did thus in our existing syntax:

x? ( !x? ( blah ) )

Worth noting, you didn't ban that from exherbo; you left that to sort 
itself out, same as I'm doing for dep:blah flags.  Were I punching 
below the belt, the word 'hypocritical' would likely be involved.


> The second is that it starts the conceptual shift from "cat/pkg is a
> build dep, and cat/pkg is a run dep" to "cat/pkg is a dep that is
> required for build and run".

Fairly weak argument at best; you're claiming that via labels, 
"contextually they know it's these deps" in comparison to via 
dep:build "contextually they know it's exposed only in build".

Same difference.


> > 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.
> 
> No, I want something where things that are different look different.
> Dependency types are nothing like use flags, so they shouldn't look the
> same.

I'll buy that argument, and to some degree- agree.

I just view that as academic wankery without real world gain.

So like I said, academically possible, but 
pragmatically/unrealistically unneded.

No amount of arguing is going to dissuade me on that view either, 
although real world tree examples *might*- aka, stop talking, go 
analyzing.


> > 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.
> 
> The gain is that you have a syntax designed for what's being
> represented, not an existing syntax abused to sort of (but not
> quite, because it's still defined in terms of rendering down) do new
> things.
> 
> Really, all it takes to see that your syntax is bad is one tiny little
> example:
> 
>     dep:build? ( dep:run? ( cat/pkg ) )

x? ( !x? ( cat/pkg ) )

Outlaw that in paludis/exherbo, and *perhaps* I'd listen to you.

You're going into broken record mode; the fact people can do stupid 
shit if they're willingly trying to abuse the syntax isn't much of an 
argument- especially considering the PM can handle it either way, 
rendering it out to a noop.


> There shouldn't be any need to add in a repoman check to catch that
> kind of thing. The problem is entirely caused by bad syntax design.
> Implementing labels is not difficult, and the extra cost is worth it to
> get a good design.

As I've said, there isn't a need for repoman checks.  It's *suggested* 
since as I've stated, the underlying idiocy should be spotted in our 
existing deps.

That said, repoman isn't necessary; such a construct solves itself via 
the deps dropping out; and before you try arguing that, your argument 
effectively would be based on "if someone specifies the deps wrong..." 
which means they're already up shit creek.

Either way, pulling another "done with this thread" bit to wrap this 
up; you don't like the proposal, got it.

In my proposal, I am addressing labels; will fold in your claims, but 
those claims basically are shit- however, if you *did* find a 
conflicting nested example that wasn't contrived, preferablly 
multiple, I'd like those examples so I can include them into the 
proposal (give labels a fair hand, basically).

I don't think you're going to find any, let alone one; some 
artificially structured ones perhaps, but I'm not interested in those- 
I'm looking for real world deps where conflicting nested is the best 
form.

Go find 'em; either way, moving on from the current discussion form 
(also known as "broken record mode").

cheers-
~harring