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

[Ciaran McCreesh <ciaran.mccreesh@googlemail.com>]

[-- Attachment #1: Type: text/plain, Size: 2585 bytes --]

On Tue, 25 Sep 2012 15:46:14 -0700
Brian Harring <ferringb@gmail.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...

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

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

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

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]