Re: [gentoo-dev] example conversion of gentoo-x86 current deps to unified dependencies
On Sun, Sep 16, 2012 at 6:15 AM, Brian Harring ferri...@gmail.com wrote: 1) 746 hits in the tree for COMMON_DEPEND; that's 2%, and the usages I'm aware of have been for literally, what it sounds like- depends that are both DEPEND and RDEPEND. CDEPEND is pretty common as well. I could 466 files with CDEPEND.
Re: [gentoo-dev] example conversion of gentoo-x86 current deps to unified dependencies
On 16 September 2012 21:15, Brian Harring ferri...@gmail.com wrote:
On Sun, Sep 16, 2012 at 03:39:22PM +0800, Ben de Groot wrote:
Thanks. I have given it a quick overview for the qt herd. I still
don't see what using DEPENDENCIES adds to what we do now with separate
*DEPEND variables. I see no convincing reason to change what we do.
Ok, so here's some stats: in the tree, we have 31360 ebuilds, and 194
eclasses; grand total of 31554 sources of metadata content (I say
metadata since vapier has eblits in use which are just phase
functions- I'm not scanning those intentionally).
Doing some simple scans of the tree, here's some stats; note these
stats are duplicated in the glep (they're nice selling points, thus
might as well):
1) 746 hits in the tree for COMMON_DEPEND; that's 2%, and the usages
I'm aware of have been for literally, what it sounds like- depends
that are both DEPEND and RDEPEND.
2) scanning for assignments of RDEPEND=.*|$\{?DEPEND\}? gets a hit on
5343 unique sources. Searching for the inverse gets a hit on 10008
unique sources. Meaning that right there, ~48.6% of the tree is
duplicating deps between the two forms. This puts us to 16083 unique
sources in the tree that would benefit in some form (~51%).
3) What's interesting about that 51% is the eapi groupings; in EAPI4,
the autosetting of RDEPEND=${RDEPEND:-${DEPEND}} was discontinued.
Roughly 50% of the initial 51% match is EAPI4; the rest are eapi0-3.
4) Again, keep in mind that the grep's in use above are single line
matches- I'm definitely missing some ebuilds, and for complex
dependencies that are appended/set by the eclass, likely missing a lot
of that too.
So... basically, people are already doing this manually with their own
intermediate vars.
And this works fine, so it doesn't warrant a cosmetic change.
Just a rough but mildly entertaining stat there's basically 8.38MB
worth of normalized, literal fricking dependency; using a crappy algo
(rather than a human doing the deps who can do it better), 37.4%
(3.1MB) of that is removed via going to dependencies. It goes
without saying that this would be a helluva lot less torturous on a
proper PM implementation that parses the tree once, and renders- let
alone repoman being able to avoid repeat scans of things it already
has examined.
Mind you, portage doesn't do that, but this would be good incentive to
do a proper tree. :)
PM internals are not really relevant to us developers. Just make it work... ;-)
The current *DEPEND system works. So again, I don't see a convincing
reason for change.
As I've said before on IRC, we need a good costs/benefits overview.
Right now I only see costs (migrating ebuilds and eclasses) and no
benefits.
Offhand... I wouldn't be pushing for this if I didn't think this would
be a boon over all- both for devs, and PMs.
I think the actual 'cost' probably got lost in the noise of the
various flames; what I'm proposing is basically zero cost for devs, it
shoves the work to the PM, leaving the option for devs to do a more
fine grained form if they can.
As soon as you expose this to devs (ebuild/eclass developers and
maintainers), you can no longer talk about zero cost.
We either have the enormous cost of migrating the whole tree to the
new system — which I understand you are not advocating because of the
cost; or we have the (lower, but not zero) cost of maintaining two
systems in the tree, which developers will have to know and understand
in order to be able to deal with them correctly. The latter will also
make eclasses needlessly more complex.
So in my opinion it is folly either way, because the costs are high,
and the benefits only cosmetic.
I'm starting a seperate thread w/ a glep for this; I think you should
take a look at the exact details of the specification including how
DEPEND/RDEPEND/PDEPEND are handled in parallel to DEPENDENCIES (short
version: if existent, they're automatically folded into DEPENDENCIES
in my proposal); the end result is basically zero pain transition,
while enabling us to start getting gains.
Which gains? The glep only talks about cosmetics...
--
Cheers,
Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] example conversion of gentoo-x86 current deps to unified dependencies
On 16 September 2012 09:20, Brian Harring ferri...@gmail.com wrote: On Sun, Sep 16, 2012 at 12:03:36AM +0200, Micha?? G??rny wrote: On Sat, 15 Sep 2012 13:33:18 -0700 Brian Harring ferri...@gmail.com wrote: To demonstrate the gain of this, we basically take the existing tree's deps, and re-render it into a unified DEPENDENCIES form. But in order to do this, we first have to decide exactly what kind of dependencies do we want to have. Then convert the tree to a separate-variable form with new dependencies. Then we can compare it with the DEPENDENCIES form and decide which one is better. Funny you mentioned that, I just finished tweaking pquery to generate real world example unified dependencies; these *are* accurate, just to be clear. Dumps are at http://dev.gentoo.org/~ferringb/unified-dependencies-example/ . Herds, if you want to see what your pkgs would look like, look at http://dev.gentoo.org/~ferringb/unified-dependencies-example/herds/ . If you'd like to see an *example effect* it has on what gets displayed to the user (aka, after all major use conditionals are stripped), look at http://dev.gentoo.org/~ferringb/unified-dependencies-example/user-visible.txt ; warning, that's a 55MB file. The syntax in use there isn't great, but as said, it's an example. Total cache savings from doing this for a full tree conversion, for our existing md5-cache format is 2.73MB (90 byes per cache entry). Calculating the savings from the ebuild/eclass standpoint is dependent on how the deps are built up, so I skipped that. The algorithim used is fairly stupid, but reasonably effectively; essentially it intersects the top level of each individual type of dep, breaking out common groupings. In other words, it won't pick up this: DEPEND=x? ( dev-util/diffball dev-util/bsdiff ) RDEPEND=x? ( dev-util/diffball ) and convert it into thus DEPENDENCIES= dep:build,run? ( x? ( dev-util/diffball dep:run? ( dev-util/diffball ) ) ) Additionally, the form used here makes *no assumption about default context*; in any final solution we use, a default context would be wise- say build,run. Again, an example of what I mean. If we said in the absense of a context, the default is dep:build,run the following: DEPEND=dev-util/diffball dev-util/bsdiff RDEPEND=dev-util/diffball de-vutil/bsdiff x? ( sys-apps/pkgcore ) PDEPEND=dev-python/snakeoil would be: DEPENDENCIES= dev-util/diffball dev-util/bsdiff dep:run? ( x? ( sys-apps/pkgcore ) ) dep:post? ( dev-python/snakeoil ) The quicky algo I used assumes no default context, thus it writes this: DEPENDENCIES= dep:build,run? ( dev-util/diffball dev-util/bsdiff ) dep:run? ( x? ( sys-apps/pkgcore ) ) dep:post? ( dev-python/snakeoil ) Etc. ~harring Thanks. I have given it a quick overview for the qt herd. I still don't see what using DEPENDENCIES adds to what we do now with separate *DEPEND variables. I see no convincing reason to change what we do. As I've said before on IRC, we need a good costs/benefits overview. Right now I only see costs (migrating ebuilds and eclasses) and no benefits. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] example conversion of gentoo-x86 current deps to unified dependencies
On Sat, 15 Sep 2012 18:20:26 -0700 Brian Harring ferri...@gmail.com wrote: On Sun, Sep 16, 2012 at 12:03:36AM +0200, Micha?? G??rny wrote: On Sat, 15 Sep 2012 13:33:18 -0700 Brian Harring ferri...@gmail.com wrote: To demonstrate the gain of this, we basically take the existing tree's deps, and re-render it into a unified DEPENDENCIES form. But in order to do this, we first have to decide exactly what kind of dependencies do we want to have. Then convert the tree to a separate-variable form with new dependencies. Then we can compare it with the DEPENDENCIES form and decide which one is better. Funny you mentioned that, I just finished tweaking pquery to generate real world example unified dependencies; these *are* accurate, just to be clear. But consider that for example Zac AxS (correct me if I recall it correctly) considered making changing the meaning of RDEPEND to install them before the build, thus effectively making 'build,run' useless. Total cache savings from doing this for a full tree conversion, for our existing md5-cache format is 2.73MB (90 byes per cache entry). Calculating the savings from the ebuild/eclass standpoint is dependent on how the deps are built up, so I skipped that. You're storing the cache in a tarball? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] example conversion of gentoo-x86 current deps to unified dependencies
On Sun, Sep 16, 2012 at 09:56:27AM +0200, Micha?? G??rny wrote: But consider that for example Zac AxS (correct me if I recall it correctly) considered making changing the meaning of RDEPEND to install them before the build, thus effectively making 'build,run' useless. I really am not trying to be a blatant dick to you, but this has /zero/ relevance. RDEPEND means required for runtime. That ain't changing. If they were discussing changing what RDEPEND meant, then they were high, period. If zac/axs want to try and make the resolver install RDEPEND before DEPEND... well, they're free to. That doesn't change the fact that the deps still must be specified correctly; in short, build,run is very much relevant. What I suspect they were intending on doing is letting the resolver work on RDEPENDS of a pkg in parallel to that pkg being built; this is a parallelization scheduling optimization, still requires accurate deps. I'm trying to be nice here, but you're very confused on this matter. Total cache savings from doing this for a full tree conversion, for our existing md5-cache format is 2.73MB (90 byes per cache entry). Calculating the savings from the ebuild/eclass standpoint is dependent on how the deps are built up, so I skipped that. You're storing the cache in a tarball? Going to assume you're not trolling, and instead use this as a way to point out that this actually *does* matter, although it's admittedly not obvious if you don't know much about the guts of package managers, or don't spend your saturday nights doing fun things like optimizing ebuild package manager performance. First, the figure is 3.204MB if default context is used; ~9.5% of the content footprint for md5-cache specifically. Little known fact; rsync transfers for gentoo are required to be --whole-file; meaning no intra-file delta compression, it transfers the whole file itself. This is done to keep cpu load on rsync nodes low (else they'd be calculating minimally 97k md4's for every sync, not counting the rolling adl32 chksum for all content dependent on the window cut off threshold- sounds minor, but it's death by a thousand cuts). For obvious reasons, the cache is the hottest part of the tree due to cascading updates due to eclass changes. In other words, that ~9.5% reduction targest the core data actually transferered in a sync. In terms of the total tree footprint, it's a 1% reduction; mostly lost in blocksize overhead unless you're using squashfs (which a decent number of folks do for speed reasons), or use tail packing FS for the tree (again, more than you'd think- known primarily due to reiserfs corruption bugs causing some hell on PM caches). There's also the fact doing this means best case, 2 less inodes per VDB entry (more once we start adding dependency types). For my vdb, I have 15523 across 798 pkgs. 1331 of that is *DEPEND, converted to DEPENDENCIES the file count is 748. Note that's preserving DEPEND, although it's worthless at this stage of the vdb. So 5% reduction in files in there. Whoopy-de-doo, right? This one I can't test as well since the only rotational media I've got these days is a hardware raid w/ a beefy cache; the closest I can manage is local network nfs to an ssd FS, so it'll have to serve as a stand in for cold cache/hot cache, and for a demonstration of why having a backend that is a 101 small individual files is bad. Best of 5 is displayed below: Iterating over the vdb, and parsing and rendering all depends for our current layout, w/ the vdb stored on nfs: cold cache: real0m30.405s user0m1.046s sys 0m0.390s hot cache: real0m16.483s user0m0.883s sys 0m0.168s non-optimized, hacked to work (known slower for parsing in comparison to the non quicky hack), iterating over the vdb, parsing all depends and rendering said depends when it's stored as DEPENDENCIES; literally, rendering DEPEND from it, RDEPEND, PDEPEND. cold cache: real0m18.329s user0m0.908s sys 0m0.280s hot cache real0m12.185s user0m0.860s sys 0m0.128s You get the idea. See the various infamous cold cache/hot cache performance tests in doubt; I can tell you that a similar trick, done in '07, literally just skipping loading USE till it was needed for provides parsing was enough to bring a 5400RPM drive's run time down from 15s to 12s for cold cache- for parsing provides *alone*, nothing else. Either way, do your own investigation, it's a good education on performance. Hopefully for the others listening, that last section was a random but useful tidbit of info; if not, pardon, just being through to make sure this point is not raised again. ~harring
Re: [gentoo-dev] example conversion of gentoo-x86 current deps to unified dependencies
On Sun, 16 Sep 2012 04:10:01 -0700 Brian Harring ferri...@gmail.com wrote: On Sun, Sep 16, 2012 at 09:56:27AM +0200, Micha?? G??rny wrote: But consider that for example Zac AxS (correct me if I recall it correctly) considered making changing the meaning of RDEPEND to install them before the build, thus effectively making 'build,run' useless. I really am not trying to be a blatant dick to you, but this has /zero/ relevance. RDEPEND means required for runtime. That ain't changing. If they were discussing changing what RDEPEND meant, then they were high, period. If zac/axs want to try and make the resolver install RDEPEND before DEPEND... well, they're free to. That doesn't change the fact that the deps still must be specified correctly; in short, build,run is very much relevant. I don't think we have made up our mind what *exactly* we want from deps. Just because we have something semi-correct right now, doesn't mean that we don't want to change that. But I guess with the whole amount of noise in here I won't ever get any definitive answer. There's also the fact doing this means best case, 2 less inodes per VDB entry (more once we start adding dependency types). For my vdb, I have 15523 across 798 pkgs. 1331 of that is *DEPEND, converted to DEPENDENCIES the file count is 748. Note that's preserving DEPEND, although it's worthless at this stage of the vdb. So 5% reduction in files in there. Whoopy-de-doo, right? So we can modify vdb now? What about all those applications which obviously are broken due to that? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] example conversion of gentoo-x86 current deps to unified dependencies
On Sun, Sep 16, 2012 at 01:21:26PM +0200, Micha?? G??rny wrote: On Sun, 16 Sep 2012 04:10:01 -0700 Brian Harring ferri...@gmail.com wrote: On Sun, Sep 16, 2012 at 09:56:27AM +0200, Micha?? G??rny wrote: But consider that for example Zac AxS (correct me if I recall it correctly) considered making changing the meaning of RDEPEND to install them before the build, thus effectively making 'build,run' useless. I really am not trying to be a blatant dick to you, but this has /zero/ relevance. RDEPEND means required for runtime. That ain't changing. If they were discussing changing what RDEPEND meant, then they were high, period. If zac/axs want to try and make the resolver install RDEPEND before DEPEND... well, they're free to. That doesn't change the fact that the deps still must be specified correctly; in short, build,run is very much relevant. I don't think we have made up our mind what *exactly* we want from deps. Are we now expecting deps to give us ponies or something? We know *exactly* what we want from deps, and their current definition- the problem isn't the definition, it's that we don't have the forms we need. Just because we have something semi-correct right now, doesn't mean that we don't want to change that. This is a no-op argument against the proposal: we can't change the deps because we might want to change the deps. It's also irrelevant due to the core basis of it being broken as fuck (described above). There's also the fact doing this means best case, 2 less inodes per VDB entry (more once we start adding dependency types). For my vdb, I have 15523 across 798 pkgs. 1331 of that is *DEPEND, converted to DEPENDENCIES the file count is 748. Note that's preserving DEPEND, although it's worthless at this stage of the vdb. So 5% reduction in files in there. Whoopy-de-doo, right? So we can modify vdb now? What about all those applications which obviously are broken due to that? You're misunderstanding the problem of the VDB. We cannot change the core structure of it- certain ebuilds currently expect to be able to find USE/IUSE at specific pathways. That's where we're blocked. Adding a new metadata key can, and has been done (defined_phases, properties, required_use, etc). Removing keys can be done. For efficiency, not writing a key if it's empty, can be and is being done. Basically, your retort again, is wildly off mark and misunderstanding the problem. I strongly suggest you go do some real research into the existing PMs, and the problems being discussed. Go read some code; you've minimally got 3 different codebases to work from, and that's not counting ML archives, tools, PMS, or the devmanul. If per you're statements, you're actually serious about writing your own PM, you're going to need to know this sort of shit /anyways/ to actually do the basic legwork of a PM, so please go do the necessary legwork if you want to persist in arguing about internals. ~harring
Re: [gentoo-dev] example conversion of gentoo-x86 current deps to unified dependencies
On Sun, 16 Sep 2012 04:49:21 -0700 Brian Harring ferri...@gmail.com wrote: On Sun, Sep 16, 2012 at 01:21:26PM +0200, Micha?? G??rny wrote: On Sun, 16 Sep 2012 04:10:01 -0700 Brian Harring ferri...@gmail.com wrote: On Sun, Sep 16, 2012 at 09:56:27AM +0200, Micha?? G??rny wrote: But consider that for example Zac AxS (correct me if I recall it correctly) considered making changing the meaning of RDEPEND to install them before the build, thus effectively making 'build,run' useless. I really am not trying to be a blatant dick to you, but this has /zero/ relevance. RDEPEND means required for runtime. That ain't changing. If they were discussing changing what RDEPEND meant, then they were high, period. If zac/axs want to try and make the resolver install RDEPEND before DEPEND... well, they're free to. That doesn't change the fact that the deps still must be specified correctly; in short, build,run is very much relevant. I don't think we have made up our mind what *exactly* we want from deps. Are we now expecting deps to give us ponies or something? We know *exactly* what we want from deps, and their current definition- the problem isn't the definition, it's that we don't have the forms we need. No, the problem is that we think we need more than we have now. Unless you're considering the whole point of this thread is cosmetics... then please leave that to Fedora or other people who are paid to change stuff just because they can. Just because we have something semi-correct right now, doesn't mean that we don't want to change that. This is a no-op argument against the proposal: we can't change the deps because we might want to change the deps. It's also irrelevant due to the core basis of it being broken as fuck (described above). What I'm trying to say is that you're making a lot of noise about cosmetics while we haven't even agreed on what's supposed to be inside. So, are we introducing this obtuse syntax for three DEPEND variables, of which the third is almost never used? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] example conversion of gentoo-x86 current deps to unified dependencies
On Sun, Sep 16, 2012 at 03:39:22PM +0800, Ben de Groot wrote:
On 16 September 2012 09:20, Brian Harring ferri...@gmail.com wrote:
Dumps are at
http://dev.gentoo.org/~ferringb/unified-dependencies-example/ .
Herds, if you want to see what your pkgs would look like, look at
http://dev.gentoo.org/~ferringb/unified-dependencies-example/herds/ .
If you'd like to see an *example effect* it has on what gets displayed
to the user (aka, after all major use conditionals are stripped), look
at
http://dev.gentoo.org/~ferringb/unified-dependencies-example/user-visible.txt
; warning, that's a 55MB file. The syntax in use there isn't great,
but as said, it's an example.
...
Additionally, the form used here makes *no assumption about default
context*; in any final solution we use, a default context would be
wise- say build,run. Again, an example of what I mean.
The dumps were regenerated; a default context of 'build,run' was
added. Basically in the absense of an explicit dep: targetting,
dep:build,run is assumed.
Essentially it makes the deps cleaner to read for the common case,
while also reducing the footprint at the cache, and vdb level; see
http://dev.gentoo.org/~ferringb/unified-dependencies-example/vdb-effect.txt
Thanks. I have given it a quick overview for the qt herd. I still
don't see what using DEPENDENCIES adds to what we do now with separate
*DEPEND variables. I see no convincing reason to change what we do.
Ok, so here's some stats: in the tree, we have 31360 ebuilds, and 194
eclasses; grand total of 31554 sources of metadata content (I say
metadata since vapier has eblits in use which are just phase
functions- I'm not scanning those intentionally).
Doing some simple scans of the tree, here's some stats; note these
stats are duplicated in the glep (they're nice selling points, thus
might as well):
1) 746 hits in the tree for COMMON_DEPEND; that's 2%, and the usages
I'm aware of have been for literally, what it sounds like- depends
that are both DEPEND and RDEPEND.
2) scanning for assignments of RDEPEND=.*|$\{?DEPEND\}? gets a hit on
5343 unique sources. Searching for the inverse gets a hit on 10008
unique sources. Meaning that right there, ~48.6% of the tree is
duplicating deps between the two forms. This puts us to 16083 unique
sources in the tree that would benefit in some form (~51%).
3) What's interesting about that 51% is the eapi groupings; in EAPI4,
the autosetting of RDEPEND=${RDEPEND:-${DEPEND}} was discontinued.
Roughly 50% of the initial 51% match is EAPI4; the rest are eapi0-3.
4) Again, keep in mind that the grep's in use above are single line
matches- I'm definitely missing some ebuilds, and for complex
dependencies that are appended/set by the eclass, likely missing a lot
of that too.
So... basically, people are already doing this manually with their own
intermediate vars.
Just a rough but mildly entertaining stat there's basically 8.38MB
worth of normalized, literal fricking dependency; using a crappy algo
(rather than a human doing the deps who can do it better), 37.4%
(3.1MB) of that is removed via going to dependencies. It goes
without saying that this would be a helluva lot less torturous on a
proper PM implementation that parses the tree once, and renders- let
alone repoman being able to avoid repeat scans of things it already
has examined.
Mind you, portage doesn't do that, but this would be good incentive to
do a proper tree. :)
As I've said before on IRC, we need a good costs/benefits overview.
Right now I only see costs (migrating ebuilds and eclasses) and no
benefits.
Offhand... I wouldn't be pushing for this if I didn't think this would
be a boon over all- both for devs, and PMs.
I think the actual 'cost' probably got lost in the noise of the
various flames; what I'm proposing is basically zero cost for devs, it
shoves the work to the PM, leaving the option for devs to do a more
fine grained form if they can.
I'm starting a seperate thread w/ a glep for this; I think you should
take a look at the exact details of the specification including how
DEPEND/RDEPEND/PDEPEND are handled in parallel to DEPENDENCIES (short
version: if existent, they're automatically folded into DEPENDENCIES
in my proposal); the end result is basically zero pain transition,
while enabling us to start getting gains.
Cheers-
~brian
Re: [gentoo-dev] example conversion of gentoo-x86 current deps to unified dependencies
On Sun, Sep 16, 2012 at 02:02:24PM +0200, Micha?? G??rny wrote: On Sun, 16 Sep 2012 04:49:21 -0700 Brian Harring ferri...@gmail.com wrote: On Sun, Sep 16, 2012 at 01:21:26PM +0200, Micha?? G??rny wrote: On Sun, 16 Sep 2012 04:10:01 -0700 Brian Harring ferri...@gmail.com wrote: On Sun, Sep 16, 2012 at 09:56:27AM +0200, Micha?? G??rny wrote: But consider that for example Zac AxS (correct me if I recall it correctly) considered making changing the meaning of RDEPEND to install them before the build, thus effectively making 'build,run' useless. I really am not trying to be a blatant dick to you, but this has /zero/ relevance. RDEPEND means required for runtime. That ain't changing. If they were discussing changing what RDEPEND meant, then they were high, period. If zac/axs want to try and make the resolver install RDEPEND before DEPEND... well, they're free to. That doesn't change the fact that the deps still must be specified correctly; in short, build,run is very much relevant. I don't think we have made up our mind what *exactly* we want from deps. Are we now expecting deps to give us ponies or something? We know *exactly* what we want from deps, and their current definition- the problem isn't the definition, it's that we don't have the forms we need. No, the problem is that we think we need more than we have now. Read what I wrote. we don't have the forms we need; a more proper statement is we don't have all of the forms we need. Please read what I write, rather than just responding blindly. You may have time to waste, but I don't, nor do the people on this ml need to see you respond 13 minutes after I send an email when you can't even be bothered to read the fucking content properly. Unless you're considering the whole point of this thread is cosmetics... then please leave that to Fedora or other people who are paid to change stuff just because they can. This isn't productive; frankly it's childish. Take it to the forums if you want to continue on tangents like this. Just because we have something semi-correct right now, doesn't mean that we don't want to change that. This is a no-op argument against the proposal: we can't change the deps because we might want to change the deps. It's also irrelevant due to the core basis of it being broken as fuck (described above). What I'm trying to say is that you're making a lot of noise about cosmetics while we haven't even agreed on what's supposed to be inside. So, are we introducing this obtuse syntax for three DEPEND variables, of which the third is almost never used? Reiterating the points again, and for the final time for you since you seem intent on riding the short bus for this particular subject: 1) This unifies the existing syntax down into a collapsed form. In doing so, there are measurable gains across the board for PM efficiency and rsync alone. 2) In unifying the syntax via reusing our /existing fucking syntax/, we formalize the adhoc common dependency assignments devs already are doing in the tree. 3) In moving to a unified syntax, it positions us to easily introduce new dependency types without introducing more redundancy. Easier to add new dep types, faster to add new dep types, more efficient in doing so in comparison to existing approaches, and done in a fashion that devs can reuse existing conditionals. 4) It is not exherbo's DEPENDENCIES. Meaning it is not label based. Meaning you do not need to knee-jerk attack it because of some notion it's ciaran based/related. Honestly, stop wasting my (and others time) and please read this email full and through, including the /full thread you're blindly responding to/ before responding again. There is no prive for having the fastest turn around time in responding to an email; not unless you consider a permenant /ignore and killfile addition to be a prize. ~harring
Re: [gentoo-dev] example conversion of gentoo-x86 current deps to unified dependencies
On 15/09/2012 18:20, Brian Harring wrote: Herds, if you want to see what your pkgs would look like, look at http://dev.gentoo.org/~ferringb/unified-dependencies-example/herds/ . Ruby team could make use of a dep:test and automatic conversion of that :P -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
