Gentoo Archives: gentoo-dev

From: Brian Harring <ferringb@×××××.com>
To: ciaran.mccreesh@××××××××××.com, mgorny@g.o
Cc: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] How to handle dependencies on protocol headers?
Date: Fri, 16 Sep 2011 09:16:04
Message-Id: 20110916091517.GE16239@localhost
In Reply to: Re: [gentoo-dev] How to handle dependencies on protocol headers? by Ciaran McCreesh
On Fri, Sep 16, 2011 at 09:08:36AM +0100, Ciaran McCreesh wrote:
> On Fri, 16 Sep 2011 09:54:47 +0200 > Micha?? G??rny <mgorny@g.o> wrote: > > > This is a build-against dependency, and it's best expressed either > > > by its own BADEPEND, or (because it's apparently now possible, and > > > because otherwise we'd end up with six or seven *DEPEND variables) > > > by switching to something like DEPENDENCIES with a build-against > > > label. > > > > Please do not wreak exheres into Gentoo. The current variable forms > > are complex enough; there is no reason to put even more logic into > > the parser. And yes, it's better to have 7 *DEPEND variables than one > > more magical, conditional thingie in the 'Dependencies' section. > > From feedback so far, I think you're in the minority on that (at least > from people who have expressed an opinion), and that more people have > come out in favour of a single unified variable (not necessarily with > exactly the same syntax as exheres-0).
Personally... I think dependencies w/ labels is fricking ugly. That said I understand the intent- being able to layer in multiple forms of deps (specifically new forms beyond what EAPI currently provides) which is good. Strikes me, this is glep territory; write it up w/ the specifics so everyone can look at it (including literal examples), and work from there. At the very least the facts would be on the table for people to read/vote on. Same instant, the folks disagreeing can pick at the failings if any, and/or write up an alternative that uses seperated vars if they think it's friendlier. Pretty much, I'd like to see this move into a realm of actual decision rather than just the current "use dependencies" "no they suck, and so do you". Alternative suggestions for moving it in that direction are welcome, but the current bickering isn't really going anywhere (this particular discussion has been appearing since eapi1 or so). Either way, we *do* need the new deps, so... getting something worked out would be preferable to having it keep dragging out. ~brian