On Sun, 16 Sep 2012 06:52:11 -0700
Brian Harring <ferringb@gmail.com> wrote:
> The live version of the doc is available at 
> http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_dependencies.html 

I think you're being a bit glib with your dismissal of the labels
parsing scheme. You've got the following problems, that labels don't
have:

You dismiss the dep:build? ( dep:run? ( ) ) problem as "don't do that".
Labels doesn't have this problem: it doesn't try to reuse an existing
syntax precisely because the existing syntax is extremely awkward for
this kind of thing.

You say there's an implict "build,run". This can't be an implicit
"dep:build,run? ( )" using that syntax, however, since then you
wouldn't be able to put a dep:post? inside it by the above. So again
you've got a special case to deal with simply because of the syntax --
your syntax doesn't correspond directly to the meaning of dependencies.

There's also the issue of what negations do at the top level...

You discourage grouping of dependencies by the use flag that selects
them (see xscreensaver in your examples). Logically, "xscreensaver
related things" belong together. Your negation example also tries to
bring related dependencies together. But it's a mess. What if one of
the dependencies was a build dependency, and one a run dependency?
You'd end up with something silly like this:

    dep:build,run? (
        !dep:run? ( dev-util/diffball )
        !dep:build? ( dev-util/bsdiff )
    )

Your syntax also prevents the following:

    DEPENDENCIES="foo? ( $(make_foo_deps blah) )"

and would encourage something like this instead:

    DEPENDENCIES="
        dep:build? ( foo? ( $(make_foo_build_deps blah) ) )
        dep:run? ( foo? ( $(make_foo_run_deps blah) ) )
        dep:build,run? ( foo? ( $(make_foo_build_and_run_deps blah) ) )

which makes it much harder for the foo.eclass authors to switch what
kinds of dependencies they use. For example, if foo.eclass starts
needing an install dependency, your syntax requires every foo user to
be updated, whereas labels does not. To get around that, you'd have to
allow deeply embedded dep: blocks.

You're also still speaking in terms of "rendering DEPEND" etc. That's
not really what we want, though. As you've observed, a lot of atoms are
in both DEPEND and RDEPEND. Conceptually, it makes much more sense to
consider such an atom to be a single dependency that is both a build
and a runtime dependency than it does to consider it as two unrelated
dependencies. This is especially the case now that we have := slot
dependencies.

Ultimately, it comes down to the observation that the flag? ( ) syntax
is strongly nested and hierarchical, but dependency roles aren't.
Labels can give all the advantages of your proposal (including the
backwards compatibility, if that's desired), but without the need to
shoehorn the idea into an unsuitable syntax.

-- 
Ciaran McCreesh