Re: [gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/09/12 05:53 PM, Ciaran McCreesh wrote: On Sun, 30 Sep 2012 14:42:14 -0700 Brian Harring ferri...@gmail.com wrote: 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. So you would using your labels syntax, specify an atom with a := dep using certain labels and the same atom without ':=' on other labels? I don't quite follow what you're getting at here as to how this is a big deal.. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBrKYUACgkQ2ugaI38ACPAMJAD9FzCH4ifbkanbC17w2KGjMHP7 G4qBrJ9v2dd7sHV338EA/iK/J+NZosc+M7wefJ8J6fU4mVczlM4WiOkCNVsTSO6w =Io2B -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 02 Oct 2012 13:51:01 -0400 Ian Stakenvicius a...@gentoo.org wrote: On 30/09/12 05:53 PM, Ciaran McCreesh wrote: On Sun, 30 Sep 2012 14:42:14 -0700 Brian Harring ferri...@gmail.com wrote: 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. So you would using your labels syntax, specify an atom with a := dep using certain labels and the same atom without ':=' on other labels? I don't quite follow what you're getting at here as to how this is a big deal.. A := only makes sense for a dependency that is present both at build time and at runtime. Currently, the only place you should be seeing a := is on a spec that is listed in both DEPEND and RDEPEND. Conceptually, the := applies to the spec that is in both DEPEND and RDEPEND. But with the current syntax, there's no such thing as the spec that is in both. There are two specs, which happen to be identical as strings, one in DEPEND and one in RDEPEND, and there's no way for the two to be associated. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlBrKsEACgkQ96zL6DUtXhEyOACfQgN7K9iPf0o8NF4w95HpFq3j MHQAoKwMwmbJHuF65PIX9b6W0EQLqukl =pzQn -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/10/12 01:56 PM, Ciaran McCreesh wrote: On Tue, 02 Oct 2012 13:51:01 -0400 Ian Stakenvicius a...@gentoo.org wrote: On 30/09/12 05:53 PM, Ciaran McCreesh wrote: On Sun, 30 Sep 2012 14:42:14 -0700 Brian Harring ferri...@gmail.com wrote: 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. So you would using your labels syntax, specify an atom with a := dep using certain labels and the same atom without ':=' on other labels? I don't quite follow what you're getting at here as to how this is a big deal.. A := only makes sense for a dependency that is present both at build time and at runtime. Currently, the only place you should be seeing a := is on a spec that is listed in both DEPEND and RDEPEND. Conceptually, the := applies to the spec that is in both DEPEND and RDEPEND. But with the current syntax, there's no such thing as the spec that is in both. There are two specs, which happen to be identical as strings, one in DEPEND and one in RDEPEND, and there's no way for the two to be associated. Current syntax = *DEPEND, yes. Completely agree. In relation to Brian's proposal for DEPENDENCIES, tho, the two specs which happen to be identical strings would be rolled out from the same - -actual- string in the ebuild, and so, I don't see any such 'big deal' between the ability to conceptually express what's going on via his syntax and your labels. Unless i'm missing something, 'same difference' still fits.. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBrLYIACgkQ2ugaI38ACPBb4gD+KnH0izbhJZuhm0JD1cHG6s0D 4/0gxZk3Z+TEy9I0W84A/1Yt0ilqJ0SfNTHr9P6hjQkUvLsHzPzkh4Kiz8VMah/w =8amf -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 02 Oct 2012 14:08:02 -0400 Ian Stakenvicius a...@gentoo.org wrote: A := only makes sense for a dependency that is present both at build time and at runtime. Currently, the only place you should be seeing a := is on a spec that is listed in both DEPEND and RDEPEND. Conceptually, the := applies to the spec that is in both DEPEND and RDEPEND. But with the current syntax, there's no such thing as the spec that is in both. There are two specs, which happen to be identical as strings, one in DEPEND and one in RDEPEND, and there's no way for the two to be associated. Current syntax = *DEPEND, yes. Completely agree. In relation to Brian's proposal for DEPENDENCIES, tho, the two specs which happen to be identical strings would be rolled out from the same - -actual- string in the ebuild, and so, I don't see any such 'big deal' between the ability to conceptually express what's going on via his syntax and your labels. Unless i'm missing something, 'same difference' still fits.. Brian has DEPENDENCIES as being syntactic sugar that is rendered into separate *DEPEND variables. Conceptually, a := spec would be treated as two different, unrelated specs. If we're doing that, though, then there's not really any point in the proposal -- we want the model change, not just for := dependencies, but also to allow us to fix some of the awful mess that is ||. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlBrL2kACgkQ96zL6DUtXhE1EgCeNANLVxtyb6OSir9LqA+PB+bJ zUkAn2dV2OjMYMB95+tBUYvb3Eda4rU7 =0Cwb -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
On Tue, Oct 02, 2012 at 02:08:02PM -0400, Ian Stakenvicius wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/10/12 01:56 PM, Ciaran McCreesh wrote: On Tue, 02 Oct 2012 13:51:01 -0400 Ian Stakenvicius a...@gentoo.org wrote: On 30/09/12 05:53 PM, Ciaran McCreesh wrote: On Sun, 30 Sep 2012 14:42:14 -0700 Brian Harring ferri...@gmail.com wrote: 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. So you would using your labels syntax, specify an atom with a := dep using certain labels and the same atom without ':=' on other labels? I don't quite follow what you're getting at here as to how this is a big deal.. A := only makes sense for a dependency that is present both at build time and at runtime. Currently, the only place you should be seeing a := is on a spec that is listed in both DEPEND and RDEPEND. Conceptually, the := applies to the spec that is in both DEPEND and RDEPEND. But with the current syntax, there's no such thing as the spec that is in both. There are two specs, which happen to be identical as strings, one in DEPEND and one in RDEPEND, and there's no way for the two to be associated. Current syntax = *DEPEND, yes. Completely agree. In relation to Brian's proposal for DEPENDENCIES, tho, the two specs which happen to be identical strings would be rolled out from the same - -actual- string in the ebuild, and so, I don't see any such 'big deal' between the ability to conceptually express what's going on via his syntax and your labels. Unless i'm missing something, 'same difference' still fits.. Same difference applies; he's making the claim that the resolver can't tell that the python atom should be the same between build/run: dep:build,run? ( dev-lang/python:2.7= ) build: dev-python/snakeoil # vs labels build+run: dev-lang/python:2.7= build: dev-python/snakeoil The argument there is basically predicated on the belief that only labels can 'color' the sections it contains. This is a bullshit claim, and possibly specific to paludis internal failings. A sane implementation can walk that parse tree, and minimally infer that on it's own via the walk- or if it's saner, just track where things came from, and sort it via that way. Realistically a *good* implementation would likely be doing a partial rendering anyways (a good implementation already has the machinery for this for QA analysis reasons)- meaning conditionals beyond dep: would be finalized, leaving just those nodes unrendered, and then doing quick pass rendering of that intermediate form to get each phases specific requirements. Honestly it's a bullshit argument anyways; the unstated, but core argument of such nonsense is that the resolver if it saw dep:build? ( dev-lang/python:2.7= ) dep:run? ( dev-lang/python:2.7= ) would, because it's not one single build/run construct, think it can vary python:2.7 Any/all sane resolver already do collapsing and stabilization of common nodes across dep phases (and if paludis doesn't, well, that's their mess to sort; we're not getting any PROPERTIES=funky-slots hacks to work around their brain dead breakage here). The same situation can occur w/ labels via eclass dep manipulation; this is an artificial example, but anyone who has done deps know this sort of thing can/does occur via eclasses injecting common deps in: encode? ( build: dev-lang/python:2.7= ) build,run: dev-lang/python:2.7= Oh noes. How ever will the resolver know that it shouldn't vary the micro version of dev-lang/python:2.7 between build and run in that case! You just *know* it wants to vary the micro version because, such a completely fucking worthless thing for the resolver, it must do because it can, right? Etc. It's a pure bullshit argument, potentially derived from implementation issues for his own code, or just academic wankery; unsure of which, don't care which since the core argument is a new level of cracked out. ~harring
Re: [gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
On Tue, 2 Oct 2012 13:40:45 -0700 Brian Harring ferri...@gmail.com wrote: Same difference applies; he's making the claim that the resolver can't tell that the python atom should be the same between build/run: dep:build,run? ( dev-lang/python:2.7= ) build: dev-python/snakeoil # vs labels build+run: dev-lang/python:2.7= build: dev-python/snakeoil The argument there is basically predicated on the belief that only labels can 'color' the sections it contains. This is a bullshit claim, and possibly specific to paludis internal failings. No, it's specific to failings in the way you've written your proposal, which in turn are due to you wanting to implement it as a quick rendering hack in Portage. Unfortunately, the way you define things in terms of rendering dependencies forces everyone to emulate these failings so as to deliver a compliant handling of the || ( dep:build? ( a ) dep:run? ( b ) ) case. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
On Sun, 30 Sep 2012 16:56:56 -0700 Brian Harring ferri...@gmail.com wrote: 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. I don't know whether you're aware of this, but a small number (cost per ebuild) multiplied by a big number (lots of ebuilds) can be larger than a medium sized number (cost of implementing a good solution). I realise this is a sophisticated technique I'm using here, but I assure you multiplication has been used in some industries for a few years now. 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!). Or looking at it another way: you're so eager to deliver a compromise and a pragmatic solution (at the expense of ebuild writers everywhere) that you immediately rule out a good solution just so you can push the virtues of doing it wrong. Doing it wrong should be a last resort, not something you look to do at any given opportunity. 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. x? ( build: a run: b ) *is* nested conflicting. You're still failing to understand the point of labels parsing rules, though: the point is to make uses like the above well defined and consistent. 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). This isn't chucking out syntax. It's augmenting existing syntax. What you're doing is trying to shove something new onto an existing syntax which doesn't fit it. You should know this from REQUIRED_USE: that's a perfect example of going too far to reuse existing syntax. 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. It's about giving ebuild developers a good format to work with. That sort of thing matters. There are a lot of ebuilds and not many package manglers. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
On Mon, Oct 01, 2012 at 08:13:49AM +0100, Ciaran McCreesh wrote: x? ( build: a run: b ) *is* nested conflicting. You're still failing to understand the point of labels parsing rules, though: the point is to make uses like the above well defined and consistent. I understand them just fine; you're just either very fucking daft, which I have a hard time believing, or lieing through your teeth (which fits a decade of behaviour including multiple suspensions for exactly that behaviour). Implicit labels context is build+run. Meaning the following x? ( build: a run: b ) *is* nested conflicting. is actually build+run x? ( build: a run: b ) Which isn't a nested conflict- subset, not conflict. You argue labels are required so people can do nested conflicts; meaning the following extreme example: run x? ( build: a test: b ) And as I nicely pointed out, /not a single fucking exheres/ does that. you've yet to pull out an example contradicting that analysis in addition. So... with that in mind- I'm doing two things; 1) can't force you back under a bridge, instead I'll do the killfile equivalent for a few weeks, 2) my original proposal if you kept being a tool seems appropriate: 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). What I truly love about that solution there is that it's both accurate, and if I play my cards right, I may be able to get a glep passed calling your proposal academic wankery; minimally, it'll be fun from my standpoint to try, so at least something came out of the last few emails from you. hugs and kisses- ~harring
[gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
On Mon, 1 Oct 2012 02:01:32 -0700 Brian Harring ferri...@gmail.com wrote: On Mon, Oct 01, 2012 at 08:13:49AM +0100, Ciaran McCreesh wrote: x? ( build: a run: b ) *is* nested conflicting. You're still failing to understand the point of labels parsing rules, though: the point is to make uses like the above well defined and consistent. I understand them just fine; you're just either very fucking daft, which I have a hard time believing, or lieing through your teeth (which fits a decade of behaviour including multiple suspensions for exactly that behaviour). Implicit labels context is build+run. Meaning the following x? ( build: a run: b ) *is* nested conflicting. is actually build+run x? ( build: a run: b ) Which isn't a nested conflict- subset, not conflict. As I said right at the start, you're special-casing the top level to something that can't normally be expressed using the syntax. You argue labels are required so people can do nested conflicts; meaning the following extreme example: run x? ( build: a test: b ) And as I nicely pointed out, /not a single fucking exheres/ does that. you've yet to pull out an example contradicting that analysis in addition. No, I argue that having well-defined parsing rules means it doesn't matter if someone does do that. Meaning, no special case for the top level. Your rules require a handler to say have I seen any dep: blocks further up the tree than my current position? If yes, handle this dep: block one way; otherwise, handle it a different way. With labels, all you do is initialise the label stack with build+run, and then no special case handling is required. That's what you should be putting in the GLEP. Not examples, but a big fat warning that your syntax requires a very strange special case rule to handle your default build+run behaviour. What I truly love about that solution there is that it's both accurate, and if I play my cards right, I may be able to get a glep passed calling your proposal academic wankery; minimally, it'll be fun from my standpoint to try, so at least something came out of the last few emails from you. Oh come on, we all know that unnecessarily screwing up the syntax won't make DEPENDENCIES be sufficiently un-exherbo-looking to get it passed... -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-pms] 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 ferri...@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
[gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
On Sun, 30 Sep 2012 13:14:53 -0700 Brian Harring ferri...@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 signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-pms] 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 ferri...@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
[gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
On Sun, 30 Sep 2012 14:42:14 -0700 Brian Harring ferri...@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 signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-pms] 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
[gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
On Tue, 25 Sep 2012 15:46:14 -0700 Brian Harring ferri...@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 signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-pms] 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
Re: [gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 16/09/12 12:05 PM, Brian Harring wrote:
On Sun, Sep 16, 2012 at 03:39:49PM +0100, Ciaran McCreesh wrote:
There's also the issue of what negations do at the top level...
Yeah, I did skimp on that one; technically speaking, negations
aren't required if they prove too much of a pain in the ass.
Negation at the top level could be interpretted two ways:
1) negating against all possible dep types; thus a !dep:build?
would be dep:post,run? . Too slick in my view, but who knows,
othes may think it straight forward.
2) Treat it as a negation of the implicit dep:build,run; meaning
!dep:build? would be dep:run?.
Unsure of which is preferably at this juncture.
Proposal: Negation only works within the current context. Simpler to
understand that way. So if the implicit dep:build,run is going to be
kept (iirc the glep says this is optional and for convenience, so if
we dropped it in favour of always forcing it that might be good), #2
would apply.
This would also infer that:
dep:build? ( !dep:{anything but build}? ( something ) ) would have no
meaning and the !dep:{anything but build}? condition would just be
ignored. Probably, without a QA warning since I could see eclasses
perhaps providing something in a variable or function output that
might be processed in this manner.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iF0EAREIAAYFAlBYdqYACgkQ2ugaI38ACPB41gD4ygy9SxFODJb/TlUp+23cZ36s
D+/c6gCaGXIPVoDGlQD/fsE6TcBsDnovBTVA0db4s811rTuih7JpX5LRDuABjfk=
=0eGL
-END PGP SIGNATURE-
[gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
On Sun, 16 Sep 2012 06:52:11 -0700 Brian Harring ferri...@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 signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
On Sun, Sep 16, 2012 at 03:39:49PM +0100, Ciaran McCreesh wrote:
On Sun, 16 Sep 2012 06:52:11 -0700
Brian Harring ferri...@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.
x? ( !x? ( dep ) ) already exists syntactically. dep:build? (
dep:run? ( blah ) ) is no different, so yes, I dismiss it- frankly
with prejudice since you keep bringing that example up but ignoring
that it's not a new issue (plus ignoring that it never occurs in the
wild because it's a self-solving issue).
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.
Labels have a human comprehension problem, and require a fair amount
more work for the various parsers.
You may not agree on that view, but there seems to be some consensus
on that (as much as one ever gets in gentoo at least).
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.
You're misunderstanding; you're thinking about it as to how exheres
labels are done which is basically
build+run: ${DEPENDENCIES}
One thing to keep in mind here; I don't mind making the parser do some
extra work if it's easier on devs to deal with (including
aesthetically; like it or not, dependencies is needed, and screaming
labels are the one true religion isn't going to get us to where we
need to go- pragmatic compromise will).
Either way, in the absense of an explicit dep context, dep:build,run?
is assumed. The parser/visitation implementation is admittedly more
complex, but it's not in the realm of 'hard'. This is assuming a
non-shit implementation mind you.
Either way, my focus here is on the human, as I've stated.
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.
doesn't correspond directly to the meaning of dependencies is a
vague assertion; back that one up. I'm assuming you're complaining
that conditionals are being used (the but they're not USE flags! bit
which is a subjective view of the conditional namespace).
If that's not what you're referencing, then frankly I'll just go with
explain to me how this same critique doesn't apply to labels.
There's also the issue of what negations do at the top level...
Yeah, I did skimp on that one; technically speaking, negations aren't
required if they prove too much of a pain in the ass. Negation at the
top level could be interpretted two ways:
1) negating against all possible dep types; thus a !dep:build? would
be dep:post,run? . Too slick in my view, but who knows, othes may
think it straight forward.
2) Treat it as a negation of the implicit dep:build,run; meaning
!dep:build? would be dep:run?.
Unsure of which is preferably at this juncture.
You discourage grouping of dependencies by the use flag that selects
them (see xscreensaver in your examples). Logically, xscreensaver
related things belong together.
I do not discourage grouping. The example is an automated
conversion, as explicitly mentioned in the doc.
A secondary condensing of those deps I'll add to make clear it's
supported.
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 )
)
Ciaran, we use a fucking bash format. We lost the ability to block
silly idiocy long ago via that choice.
As said, 'x? ( !x? ( dep ) )' already exists, despite being dumb. The
beauty of it however is that the syntax rules themselves make it such
that it doesn't ever actually come up in real world usage- the dep
wouldn't be used fundamentally.
My intention is a syntax/format that is natural to the dev, and
doesn't force them to do silly shit. If they choose to do silly shit,
that's on their head; trying to explicitly ban all possible dumb uses
just makes the rules worse via increased complexity.
Also, just to be clear, this critique applies to exheres labels just
the same. That example, rewritten to drop the negations is thus:
dep:build,run? (
dep:build? ( dev-util/diffball )
dep:run? ( dev-util/bsdiff )
)
Yep. That's pretty dumb. But no less retarded than someone doing the
following in labels:
build+run:
build: dev-util/diffball
run: dev-util/bsdiff
Which I'll note isn't banned in your usage,
[gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
On Sun, 16 Sep 2012 09:05:28 -0700 Brian Harring ferri...@gmail.com wrote: 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. Labels have a human comprehension problem, and require a fair amount more work for the various parsers. You may not agree on that view, but there seems to be some consensus on that (as much as one ever gets in gentoo at least). I've never heard that view coming from anyone who has actually used labels. It's only come from people who haven't tried using it, and who have a history of disagreeing with anything that says 'Exherbo' on it. You're taking about consensus among people who have never tried it because they don't like it; consensus among people who have tried it is that the labels syntax is good. My intention is a syntax/format that is natural to the dev, and doesn't force them to do silly shit. Labels already solve that. We know because we've got extensive experience with them. Adoption of labels has been demonstrated to be easy, both for former Gentoo developers and for people who haven't previously written ebuilds. We *know* that labels are easy to learn and easy to use. We also know that they admit an efficient implementation, that they compose nicely, that they allow dependencies to be specified accurately and that they scale to larger numbers of dependency classes. 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. 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 ) ) 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. 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. -- Ciaran McCreesh signature.asc Description: PGP signature
