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

[Ciaran McCreesh]

On Sun, 30 Sep 2012 13:14:53 -0700
Brian Harring <ferringb@×××××.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.

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

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

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

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

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.

-- 
Ciaran McCreesh