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, 01:52 PM
Brian Harring
 
Default GLEP: gentoo sync based unified deps proposal

Folks-

Keeping it short and quick, a basic glep has been written for what I'm
proposing for DEPENDENCIES enhancement.

The live version of the doc is available at
http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_dependencies.html

Wording fixes will occur, but the core concept shouldn't change (and
if it does, per PEP standards, the changes will be noted/tracked).

Please have a read through; it should be clear/concise as to why PM
authors are pushing for a unified dependencies to be done, what we can
get from it now, what it enables moving forward, and the direct cost
to devs should this idea be implemented.

Just to be absolutely clear, what I'm proposing is basically zero cost
for devs- they can (and should when it's in their benefit) switch to
the new syntax when it makes their job easier; it can be used in
parallel to existing DEPEND/RDEPEND/PDEPEND both to ease
transition/compatibility.

In addition, a prototype portage patch has been cut for dependencies
support (needs work/full validation), and a matching pkgcore one has
been cut.

I realize it's a complex subject; if you have questions, please feel
to ask.

Thanks, and pardon the ancillary/daft noise that has gone with this
subject.

~harring
 
Old 09-16-2012, 02:39 PM
Ciaran McCreesh
 
Default GLEP: gentoo sync based unified deps proposal

On Sun, 16 Sep 2012 06:52:11 -0700
Brian Harring <ferringb@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 depost? 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
 
Old 09-16-2012, 04:05 PM
Brian Harring
 
Default 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 <ferringb@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 depost? 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 depost,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, despite the idiocy of such
a construct.



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

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

This critique is based on the same misunderstanding, just to be clear.


> You're also still speaking in terms of "rendering DEPEND" etc.

Babysteps. First switch the internals to DEPENDENCIES, render from
that to *DEPEND; in doing so, it's minimally disruptive for the PM,
and for devs.

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

Agreed, but we're not going to get to where we want without going
through transition phases; at the PM level, minimally these
enhancements:

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.
2) Start converting the internals of the PM over such that it
operates, directly from that parsed tree, rathrer having to
operate on a flatten/reduced/rendered version of it for each
context.
3) Once that's in place, start teaching the resolver how to make
better decisions via the better dependency groupping.

That's the rough roadmap for PM's were this to be added, exempting
integration of any new dependency types.

For devs, they're not going to migrated at the flip of a switch. Thus
the same general transition approach;

1) switch the focus to DEPENDENCIES via collapsing
depend/rdepend/pdepend into it. This allows existing code to work
in EAPI5 (or whichever this lands in).
2) New dependency forms should be added to DEPENDENCIES only; this is
a bit of a carrot to get folks to migrate.
3) As ebuilds/eclasses get further along, and <EAPI5 support gets
increasingly dropped, devs are encouraged (and hopefully willing
since the syntax should make their lives easier) to migrate to the
new form.
4) Some point down the line when we've neared an appropriate critical
mass, we discontinue the no longer necessary *DEPEND appending into
DEPENDENCIES; basically deprecate and/then ban *DEPEND in the EAPI
of that day. *DEPEND fades into the dust, same as how implicit
RDEPEND=${RDEPEND-${DEPEND}} was phased out.


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

That said, just because it *is*, doesn't mean it has to get in the
way. Devs are already quite familiar w/ the hierarchical/nesting
behaviour of flag? ( ); I seriously doubt they are going to have
problems making dep:* work.

Basically, yes, there are some limitations; do they matter? Not
really, no.

Is it a perfect scheme? While a neat reuse of existing syntax, no,
it's not perfect.

But it's realistic, and *doable*. That counts for a fucking helluva
lot more than chasing the perfect solution.

I expect you'll inject some rant, but frankly REQUIRED_USE is a good
example of what I'm talking about; the synax sucks, it's a bit
painful, but it filled a needed gap and got the job done- 10% of EAPI4
ebuild are using it after all (please skip the required-use rant also,
whatever the flaws, one cannot argue w/ the usage).


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

Either way, you push your syntax, I'll push mine; I'm fine w/ devs
choosing the one that best fits their flow.

~harring
 
Old 09-16-2012, 04:32 PM
Alex Alexander
 
Default GLEP: gentoo sync based unified deps proposal

On Sep 16, 2012 4:55 PM, "Brian Harring" <ferringb@gmail.com> wrote:

>

> Folks-

>

> Keeping it short and quick, a basic glep has been written for what I'm

> proposing for DEPENDENCIES enhancement.

>

> The live version of the doc is available at

> http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_dependencies.html

Am I the only one who thinks that this dep:{build,...} thing looks really ugly and is hard to read?

IMO simply removing the "dep" part would greatly improve things:

DEPENDENCIES="

:build,run? ( ... )

:run? ( ... )

"

s/:/@/ would also be interesting

DEPENDENCIES="

@build,run? ( ... )

@run? ( ... )

"

Alex | wired
 
Old 09-16-2012, 04:44 PM
Ulrich Mueller
 
Default GLEP: gentoo sync based unified deps proposal

>>>>> On Sun, 16 Sep 2012, Alex Alexander wrote:

> Am I the only one who thinks that this dep:{build,...} thing looks
> really ugly and is hard to read?

+1

> IMO simply removing the "dep" part would greatly improve things:

> DEPENDENCIES="
> :build,run? ( ... )
> :run? ( ... )
> "

IMHO it would improve readability even more if we would stay with our
traditional *DEPEND variables. In any case, package managers will have
to support them indefinitely for existing EAPIs.

Ulrich
 
Old 09-16-2012, 04:59 PM
Ciaran McCreesh
 
Default GLEP: gentoo sync based unified deps proposal

On Sun, 16 Sep 2012 09:05:28 -0700
Brian Harring <ferringb@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
 
Old 09-17-2012, 03:08 AM
Brian Harring
 
Default GLEP: gentoo sync based unified deps proposal

On Sun, Sep 16, 2012 at 07:32:39PM +0300, Alex Alexander wrote:
> On Sep 16, 2012 4:55 PM, "Brian Harring" <[1]ferringb@gmail.com> wrote:
> >
> > Folks-
> >
> > Keeping it short and quick, a basic glep has been written for what
> I'm
> > proposing for DEPENDENCIES enhancement.
> >
> > The live version of the doc is available at
> >
> [2]http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_depe
> ndencies.html
>
> Am I the only one who thinks that this dep:{build,...} thing looks
> really ugly and is hard to read?
>
> IMO simply removing the "dep" part would greatly improve things:

That 'dep' part isn't great, but it's added for a reason; to unify
with USE_EXPAND/use group intended syntax. There's a reference in
there to
http://www.gossamer-threads.com/lists/gentoo/dev/260069#260069 which
I'll formalize soon enough.


> DEPENDENCIES="
> :build,run? ( ... )
> :run? ( ... )
> "

For your suggestion, consider it if we *do* fxi USE expand- via using
the same <namespace>:<setting> form.

Using app-admin/mcollective ad an example, it's deps are thus:

DEPEND="ruby_targets_ruby18? ( dev-lang/ruby:1.8 )
ruby_targets_ree18? ( dev-lang/ruby-enterprise:1.8 )"
RDEPEND="dev-ruby/stomp
ruby_targets_ruby18? ( dev-lang/ruby:1.8 )
ruby_targets_ree18? ( dev-lang/ruby-enterprise:1.8 )"

Which, if USE_EXPAND targets were groupped, would go from this
ruby_targets_ruby18? ( dev-lang/ruby:1.8 )
ruby_targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
dep:run? ( dev-ruby/stomp )"

to this:
ruby:targets_ruby18? ( dev-lang/ruby:1.8 )
ruby:targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
:run? ( dev-ruby/stomp )



> s/:/@/ would also be interesting

Just a note; the character choosen was *intentionally* one that isn't
a valid use character. @ is a valid character due to linguas. See
the thread I referenced (ciaran's response, then my response).

Short version; to use @, we need use subgroups; thus
linguas@ca@valencia .


> DEPENDENCIES="
> @build,run? ( ... )
> @run? ( ... )
> "

DEPENDENCIES="
ruby@targets_ruby18? ( dev-lang/ruby:1.8 )
ruby@targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
@run? ( dev-ruby/stomp )"

Using equivalent syntax for mcollective.

I'm not a huge fan of dep:, and I'm a bit wary of a bare
@{run,test,whatever} since it carries with it an implicit "this is
targetting the dep namespace".

That said, I'm not opposed to it- just as I said, I'm a bit wary at
first glance.

Comments?
~harring
 
Old 09-17-2012, 05:31 AM
Peter Stuge
 
Default GLEP: gentoo sync based unified deps proposal

Brian Harring wrote:
> Comments?

: is used for namespaces elsewhere too. The familiarity is good.


//Peter
 
Old 09-17-2012, 05:56 AM
Brian Dolbec
 
Default GLEP: gentoo sync based unified deps proposal

On Sun, 2012-09-16 at 06:52 -0700, Brian Harring wrote:
> Folks-
>
> Keeping it short and quick, a basic glep has been written for what I'm
> proposing for DEPENDENCIES enhancement.
>
> The live version of the doc is available at
> http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_dependencies.html
>
> Wording fixes will occur, but the core concept shouldn't change (and
> if it does, per PEP standards, the changes will be noted/tracked).
>
> Please have a read through; it should be clear/concise as to why PM
> authors are pushing for a unified dependencies to be done, what we can
> get from it now, what it enables moving forward, and the direct cost
> to devs should this idea be implemented.
>
> Just to be absolutely clear, what I'm proposing is basically zero cost
> for devs- they can (and should when it's in their benefit) switch to
> the new syntax when it makes their job easier; it can be used in
> parallel to existing DEPEND/RDEPEND/PDEPEND both to ease
> transition/compatibility.
>
> In addition, a prototype portage patch has been cut for dependencies
> support (needs work/full validation), and a matching pkgcore one has
> been cut.
>
> I realize it's a complex subject; if you have questions, please feel
> to ask.
>
> Thanks, and pardon the ancillary/daft noise that has gone with this
> subject.
>
> ~harring
>

I like the idea of a unified DEPENDENCIES. Potential flame wars aside,
I also like the extended USE flag syntax approach. While it would be
nice to loose the repetitive "dep:" portion, I can understand the
importance of maintaining a namespace ID to prevent it from being
injected where it does not belong. It adds to the consistency of the
USE flag syntax while condensing the results. Reducing the size will
help speed things along as well as reduce resource overhead (rsyncing
the tree).

I think it will be a good step forward in the evolution of gentoo.

I would also put forth effort to help with tools to help devs migrate
and check correctness before committing.
--
Brian Dolbec <dolsen@gentoo.org>
 
Old 09-17-2012, 10:55 AM
Alex Alexander
 
Default GLEP: gentoo sync based unified deps proposal

On Sep 17, 2012 6:13 AM, "Brian Harring" <ferringb@gmail.com> wrote:

>

> On Sun, Sep 16, 2012 at 07:32:39PM +0300, Alex Alexander wrote:

> > * *On Sep 16, 2012 4:55 PM, "Brian Harring" <[1]ferringb@gmail.com> wrote:

> > * *>

> > * *> Folks-

> > * *>

> > * *> Keeping it short and quick, a basic glep has been written for what

> > * *I'm

> > * *> proposing for DEPENDENCIES enhancement.

> > * *>

> > * *> The live version of the doc is available at

> > * *>

> > * *[2]http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_depe

> > * *ndencies.html

> >

> > * *Am I the only one who thinks that this dep:{build,...} thing looks

> > * *really ugly and is hard to read?

> >

> > * *IMO simply removing the "dep" part would greatly improve things:

>

> That 'dep' part isn't great, but it's added for a reason; to unify

> with USE_EXPAND/use group intended syntax. *There's a reference in

> there to

> http://www.gossamer-threads.com/lists/gentoo/dev/260069#260069 which

> I'll formalize soon enough.

>

>

> > * *DEPENDENCIES="

> > * *:build,run? ( ... )

> > * *:run? ( ... )

> > * *"

>

> For your suggestion, consider it if we *do* fxi USE expand- via using

> the same <namespace>:<setting> form.

>

> Using app-admin/mcollective ad an example, it's deps are thus:

>

> DEPEND="ruby_targets_ruby18? ( dev-lang/ruby:1.8 )

> * * * * ruby_targets_ree18? ( dev-lang/ruby-enterprise:1.8 )"

> RDEPEND="dev-ruby/stomp

> * * * * ruby_targets_ruby18? ( dev-lang/ruby:1.8 )

> * * * * ruby_targets_ree18? ( dev-lang/ruby-enterprise:1.8 )"

>

> Which, if USE_EXPAND targets were groupped, would go from this

> * ruby_targets_ruby18? ( dev-lang/ruby:1.8 )

> * ruby_targets_ree18? ( dev-lang/ruby-enterprise:1.8 )

> * dep:run? ( dev-ruby/stomp )"

>

> to this:

> * ruby:targets_ruby18? ( dev-lang/ruby:1.8 )

> * ruby:targets_ree18? ( dev-lang/ruby-enterprise:1.8 )

> * :run? ( dev-ruby/stomp )


Ok, now I get it. I've read the other threads as well, but failed to put it all together. Happens when you barely sleep every night :-)


I don't like this mix of dependency types and use flag deps. It smells trouble. Dependency types should be easy to separate and read, but the above example is a mess, "dep:" or no "dep:".


Why? Because you have to scan the whole thing to sort out which lines are dependency types and which lines are use deps and even then it would be easy to misread something.


If we want to stay away from labels (which aren't that bad IMO), I'd* recommend the following instead:


Force explicit setting of the dependency type and disallow the mix of dependency types and use flag deps at the same level / block.


DEPENDENCIES="

* :build,run? ( lib/foo )

* :run? (

*** lib/bar

*** someuseflag? ( random/app )

* )

* :*? (

*** thing? (

***** :build? ( lib/thing )

***** :run? ( lib/thingrunner )

*** )

"


Or, using your example:


:build,run? (

* ruby:targets_ruby18? ( dev-lang/ruby:1.8 )

* ruby:targets_ree18? ( dev-lang/ruby-enterprise:1.8 )

)

:run? ( dev-ruby/stomp )


Alex | wired
 

Thread Tools




All times are GMT. The time now is 04:29 PM.

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