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

[Ciaran McCreesh]

On Sun, 30 Sep 2012 14:42:14 -0700
Brian Harring <ferringb@×××××.com> wrote:
> Reality is, our current form can handle deps generally fine- what you
> label as trivial is the vast majority- I argue effectively all.

We could do away with half of the current feature set if we were only
interested in making things nice for the "vast majority" of cases...

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

No, label behaviour is local, and scope independent.

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

That's "not fixing an existing screw-up", which is not the same at all
as "adding a new screw-up".

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

It's rather a big deal now that we have := dependencies.

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

Labels are almost as easy to implement as your "filtering" model, and
they come with the benefit of a better syntax for developers. Even if
labels are noticably more work to implement, which I'm not convinced is
the case, it's worth paying that price a couple of times in package
manglers rather than having developers pay the price of worse syntax in
thousands of ebuilds. Filtering is a whole new mechanism anyway.

But here's the thing: when you sell something as "pragmatic", what
you're really saying is "it's wrong, I know it's wrong, and I'm going
to pretend that wrong is a good thing". Getting it wrong should be
something you do only after you're sure you can't afford get it right;
it shouldn't be something you're proud of.

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

You already have an example in your proposal, in the form of mplayer's
X? ( ) dependencies.

But that's missing the point. Even if you pretend complicated
dependencies don't exist, labels are still by far the better proposal.
Your argument boils down to "it's more pragmatic to do a quick and dirty
implementation in Portage and thus force the technical debt onto every
single ebuild than it is to do it cleanly".

-- 
Ciaran McCreesh