FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 09-25-2012, 10:46 PM
Brian Harring
 
Default GLEP: gentoo sync based unified deps proposal

Pardon the delay; got busy with work, plus to actually address your
claims re: labels (or refute, as I intend to do)... data was
necessary.

So I went and got the data.

Analysis was done roughly 09/17 or so; just looping back and
commenting now however.


On Sun, Sep 16, 2012 at 05:59:21PM +0100, Ciaran McCreesh wrote:
> > > Your syntax also prevents the following:
> > >
> > > DEPENDENCIES="foo? ( $(make_foo_deps blah) )"
> >
> > Err, no it doesn't. I think you're reading too literally into the
> > example mplayer translation I put in the doc- again, that was just a
> > quicky, automated form, you can push dep:blah down beneath
> > conditionals as necessary/desired.
> >
> > If you see something claiming otherwise, or implying otherwise in the
> > glep, please tell me exactly where so I can fix the wording.
>
> The point is that nesting prevents composition. Labels are context
> insensitive, which allows groups of dependencies to be added anywhere,
> whereas dep: blocks can only be added if the surrounding groups are
> specified in a particular way.

Fun fact; peoples usage of labels in exherbo is thus:

build+run:
set of deps
run:
set of deps/conditionals/etc

You get the idea. Technically, each block is usually wrapped in
()... which frankly is a sign that the context switch third party
code can introduce is problematic. Basically, y'all are
already using labels in exactly the fashion I propose, just
with different synax.

I couldn't find a *single* instance of the following in usage in any git.exherbo repo:

build+run:
dep1
x? (
dep2
test:
dep3
)

Ie, a nested override.

Exherbo deps themselves basically dispute the claim that nesting
somehow blocks people from doing composition; fact is, y'all can do
nesting/context switching of a label w/in a block, but y'all don't at
all. This strongly makes me think you're either blowing smoke up
folks asses or that you're chasing perfection ignoring the realities
of how this is used on the ground.

Now, if there are actually examples of it in use in y'alls trees-
(ones that aren't added after I send this email mind you ) please
point them out. Offhand, there's actually 4 pkgs that do
stacking/nesting of deps, although it's accidental and doesn't
actually do it for gain. They are:

dev-haskell/language-c[=0.3.2]::haskell
dev-haskell/language-javascript[=0.5.2]::haskell
kde/kdemultimedia[~scm]::kde
kde/kdemultimedia[=4.8.5]::kde

basically
DEPENDENCIES="
( build: some deps
# dev forgot to close the block
$(some dep_generator that forces a label immediately, per the norm)
)"

While the norm is
DEPENDENCIES="
( build: some deps )
( $(some dep_generator that forces a label immediately) )"

Interesting sidenote btw; every usage I've found is directly
translatable to my proposal, w/out any loss of expression in use.

Now, it's possible I fucked up. I strongly doubt it however. Please
provide examples either way- else y'alls own dependencies disprove
your claims about nesting being evil.

Either way, the data for that is at
http://dev.gentoo.org/~ferringb/unified-dependencies/labels/translated-to-use-deps.txt


> > 1) first, collapse dependencies down, than render the *DEPEND views,
> > thus enabling easy and quick initial integration; effectively
> > no impact on the api/functionality of the PM at this phase.
>
> 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).

Worth noting, the following idiocy is valid:

x? ( dev-util/diffball )
!dev-util/diffball

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.

This is why we have QA tools.


> > > Ultimately, it comes down to the observation that the flag? ( )
> > > syntax is strongly nested and hierarchical, but dependency roles
> > > aren't.
> >
> > There is a bit of truth in that views on flag? ( ) vs the random-ass
> > context labeling (which is hierarchical- keep in mind your stack
> > pushing/popping confusion).
>
> There's not any stack confusion in practice. Labels only have slightly
> complicated rules to allow every side case to be covered. You're taking
> the "don't do that" approach to nesting weirdness; labels go the
> "specify it precisely" route instead.

In practice, all usages explicitly go out of their way to protect
themselves from the invoking context, and they use labels *exactly the
same way as dep:build,run? ( blah )* would be used.

Basically the only real world benefit I've seen of labels vs what I've
proposed is a *slight* collapsing of the tree- although that is more
than offset by the fact all dep generating functions introduce ()
barriers to protect the invoking scope from their label adjustments.

Clarifying, this is better in labels:
"""
build+run:
blah
run:
monkeys
"""
equivalent in my proposal would be
"""
blah
dep:run? ( monkeys )
"""

The difference there isn't exactly world shattering, so it's not a
strong arguing point for labels.


> > > 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.
> >
> > If you want your proposal to go anywhere, you're going to need a
> > better transition plan then "and.... then devs convert their
> > ebuilds/eclasses". I'd suggested it prior, but no traction there.
>
> Your "rewrite *DEPEND" approach can just as easily be used with labels.

Just the same as the real world usage of labels could just as easily
be done via dep:blah.

Not sure it's worth continuing this discussion point frankly; there is
equivalence for all real world usage. Not really in dispute (you'll
try I'm sure, but without actual backing examples this time around I'm
not particularly interested in listening).

If what you've got to say is "you can do this in labels, and I think
you should labels"; ok, noted, end of discussion.

Other points I'm interested in; the mentioning of "what does
!build:test? ( blah ) mean while in implicit build,run" for example
was useful and a valid critique (one I've not yet addressed in the
doc); stuff like that you've got a better chance killing my proposal
then continuing with the "yes but labels are better than sliced bread.
you just don't understand" angle of discussion

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

~harring
 
Old 09-26-2012, 06:58 AM
Michał Górny
 
Default GLEP: gentoo sync based unified deps proposal

On Sun, 16 Sep 2012 06:52:11 -0700
Brian Harring <ferringb@gmail.com> wrote:

> Keeping it short and quick, a basic glep has been written for what I'm
> proposing for DEPENDENCIES enhancement.
>
> The live version of the doc is available at
> http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_dependencies.html

One more question -- are we going to keep 'foo,bar?' syntax as
a special case applying only to dependency atoms or are we going to
extend it to USE flags?

--
Best regards,
Michał Górny
 
Old 09-26-2012, 10:33 AM
Brian Harring
 
Default GLEP: gentoo sync based unified deps proposal

On Wed, Sep 26, 2012 at 08:58:54AM +0200, Micha?? G??rny wrote:
> On Sun, 16 Sep 2012 06:52:11 -0700
> Brian Harring <ferringb@gmail.com> wrote:
>
> > Keeping it short and quick, a basic glep has been written for what I'm
> > proposing for DEPENDENCIES enhancement.
> >
> > The live version of the doc is available at
> > http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_dependencies.html
>
> One more question -- are we going to keep 'foo,bar?' syntax as
> a special case applying only to dependency atoms or are we going to
> extend it to USE flags?

It's fairly dep specific; that's effectivelly foo|bar when you think
about it; it multiplies out to dep:foo? ( that block ) dep:bar? ( that
block ) in a dumb PM (smarter one just leaves the tree collapsed and
filters as it goes).

Phrased another way, I'm not sure we really need shorthand for the
following:

x? ( blah )
y? ( blah )
z? ( blah )

into
x,y,z? ( blah )

It's a rare case; I could only foresee that potentially being of use
for arch flags; ie, amd64,x86? ( blah ); which I'd write as
"arch:amd64,x86? ( blah )" personally since I don't like the notion of
introducing ',' into raw, non use group flags.

That said, I don't hugely care; people think it's useful, then have at
it.
~harring
 
Old 09-28-2012, 12:17 PM
Brian Harring
 
Default GLEP: gentoo sync based unified deps proposal

On Wed, Sep 26, 2012 at 08:58:54AM +0200, Micha?? G??rny wrote:
> On Sun, 16 Sep 2012 06:52:11 -0700
> Brian Harring <ferringb@gmail.com> wrote:
>
> > Keeping it short and quick, a basic glep has been written for what I'm
> > proposing for DEPENDENCIES enhancement.
> >
> > The live version of the doc is available at
> > http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_dependencies.html
>
> One more question -- are we going to keep 'foo,bar?' syntax as
> a special case applying only to dependency atoms or are we going to
> extend it to USE flags?

Note that's dep:foo,bar; not a bare "allow any use flags to be OR'd
together". In light of the fact it *is* just an expansion hack, the
usage is semi limited although there are scenarios for it; arches,
namely (if amd64 or x86, use this, if mips, that, etc).

I have no preference either way; extending it outside of dep isn't
necessary if people hate it, although as said, there are some
potential uses for it.

That said, if we were to start using it, the ',' as an 'or' operator
mildly sucks; dep:build|run also sucks (hard to read), and
dep:build+run, to me at least, implies 'and'. And yep, bikeshedding
potential there.

~harrin
 
Old 09-29-2012, 04:05 PM
Ciaran McCreesh
 
Default GLEP: gentoo sync based unified deps proposal

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
 
Old 09-30-2012, 08:14 PM
Brian Harring
 
Default GLEP: gentoo sync based unified deps proposal

On Sat, Sep 29, 2012 at 05:05:09PM +0100, Ciaran McCreesh wrote:
> 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...

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.

Considering I've not found any examples where nesting /would/ be
useful, I'm inclined to agree w/ y'alls usage- that nesting doesn't
matter.

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


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

Er, I assume you left out some chars there. The rendered version
there isn't ( a b ); in old form it is:
DEPEND=|| ( a )
RDEPEND=|| ( b )

This is why I label it a stupid use of syntax, but not ultimately
harmful.


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

Na uh, you're the smelly face!

As I said, and via correcting your misrendering, this isn't
introducing anything truly new here; people can/have done '|| ( a )';
it's a stupid construct, and for paludis it means it /does/ treat that
as an OR block (for hte rest, we do the more obvious tree collapses
during parsing, folding "a ( b )" down into "a b", same for "a || ( b
)" into "a b" since they're the same thing).


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

Again, you're pulling a "na uh, you're the smelly face" counter
argument.

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.

Now, for exherbo were y'all lack actual versioned format (exheres-0
has changed heavily since it's inception), and chucked everything and
did it from scratch (right? or do I need to do a copyright analysis
in addition?)... the situation differs. You can invent whatever
syntax you want, since you're starting from scratch, changing the
mental mode for parsing is fine.

We however are *not* starting from scratch. This shifts what we'll
accept for costs/gains ratio; frankly, the fact y'all don't make use
of those claimed 'gains' makes me think y'all tried something and it
turned out to be non-useful; it occurs in formats (ebuild format is
littered w/ shit like that unfortunately).

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.

~harring
 
Old 09-30-2012, 08:30 PM
Ciaran McCreesh
 
Default GLEP: gentoo sync based unified deps proposal

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.

> 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
 
Old 09-30-2012, 09:42 PM
Brian Harring
 
Default GLEP: gentoo sync based unified deps proposal

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
 
Old 09-30-2012, 09:53 PM
Ciaran McCreesh
 
Default GLEP: gentoo sync based unified deps proposal

On Sun, 30 Sep 2012 14:42:14 -0700
Brian Harring <ferringb@gmail.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
 
Old 09-30-2012, 11:56 PM
Brian Harring
 
Default GLEP: gentoo sync based unified deps proposal

On Sun, Sep 30, 2012 at 10:53:40PM +0100, Ciaran McCreesh wrote:
> 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.

No, when I say pragmatic, what I'm actually saying is that people who
can't focus on cost/gain, by large, haven't had real jobs (else they
would've had that perfectionism/decreasing gains ground out of them
sooner or later), and are spending their time whacking off chasing a
mythical 'perfect' solution.

Academic wankery, is the short version. You're good at technical, but
you frequently do the academic wanking crap which leads to things
dead-ending... plus wasted time because to you, 'pragmatic' is a dirty
word (compromise? Heaven forbid!).


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

I said nested conflicting labels. Meaning
"build: x? ( dar run: blah )"

which isn't the case for any of mplayer deps.

Actual examples from the tree where a conflicting nested label is
preferable. That isn't one of 'em, and you're unwillingness/inability
to point out real world examples is just digging a deeper ditch for
your argument.


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

My argument boils down to thus:

We are not exherbo- we do not have the luxury of chucking out syntax
and pulling NIH renaming of things for shits and giggles. Especially
if the new syntax is directly translatable into a tweak of our
existing syntax (a tweak that we should do anyways- recall I built
this off of fixing USE_EXPAND).

Your argument boils down to "it's not labels, ignore that it's
aesthetic knob polishing (you can do the same w/ our existent
syntax, thus the analogy of waxing it I truly mean), use labels
because I'll berate you incessently till you accede".

Beauty of open source, you want it, go do it.

If in, what, 4 years? 3? You've not been able to get off your ass,
write a proposal, hell, do a portage patch (you've *never* done
portage patches of any worth, bluntly- I know this since in the past I
used to fix shit you requested), you lose your voice in the matter.

Considering your points boil down to aesthetic academic wanking at
this point... put up, or shut up, really is that simple.

As said, you come up w/ real world examples, I'll include them; else
persist and I'll just fold the academic wankery description of labels
into the glep if you'd truly like me to (or you piss me off enough I
do so to be a dick).

~harring
 

Thread Tools




All times are GMT. The time now is 03:25 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org