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-16-2012, 02:39 AM
Diego Elio Pettenò
 
Default 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
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/
 
Old 09-16-2012, 07:39 AM
Ben de Groot
 
Default example conversion of gentoo-x86 current deps to unified dependencies

On 16 September 2012 09:20, Brian Harring <ferringb@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 <ferringb@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 ) )
> depost? ( 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 ) )
> depost? ( 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
 
Old 09-16-2012, 07:56 AM
Michał Górny
 
Default example conversion of gentoo-x86 current deps to unified dependencies

On Sat, 15 Sep 2012 18:20:26 -0700
Brian Harring <ferringb@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 <ferringb@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
 
Old 09-16-2012, 11:10 AM
Brian Harring
 
Default 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:
real 0m30.405s
user 0m1.046s
sys 0m0.390s

hot cache:
real 0m16.483s
user 0m0.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:
real 0m18.329s
user 0m0.908s
sys 0m0.280s

hot cache
real 0m12.185s
user 0m0.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
 
Old 09-16-2012, 11:21 AM
Michał Górny
 
Default example conversion of gentoo-x86 current deps to unified dependencies

On Sun, 16 Sep 2012 04:10:01 -0700
Brian Harring <ferringb@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
 
Old 09-16-2012, 11:49 AM
Brian Harring
 
Default 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 <ferringb@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
 
Old 09-16-2012, 12:02 PM
Michał Górny
 
Default example conversion of gentoo-x86 current deps to unified dependencies

On Sun, 16 Sep 2012 04:49:21 -0700
Brian Harring <ferringb@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 <ferringb@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
 
Old 09-16-2012, 01:15 PM
Brian Harring
 
Default 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 <ferringb@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
 
Old 09-16-2012, 01:38 PM
Brian Harring
 
Default 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 <ferringb@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 <ferringb@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
 
Old 09-18-2012, 10:51 PM
Matt Turner
 
Default example conversion of gentoo-x86 current deps to unified dependencies

On Sun, Sep 16, 2012 at 6:15 AM, Brian Harring <ferringb@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.
 

Thread Tools




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

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