Re: [gentoo-dev] Unified DEPENDENCIES concept

[Brian Harring <ferringb@gmail.com>]

On Fri, Sep 14, 2012 at 07:18:54AM +1200, Kent Fredric wrote:
> On 11 September 2012 14:16, Brian Harring <ferringb@gmail.com> wrote:
> > On Fri, Sep 07, 2012 at 04:14:17PM -0400, Ian Stakenvicius wrote:
> >> Is there anything in particular in the spec/proposal for DEPENDENCIES
> >> that would exclude the addition of individual "build: app-cat/myatom"
> >> "run: app-cat/myatom" deps by an eclass or eclasses?  I know the
> >> "goal" here is to make things atom-centric, but I can't see an
> >> implementation ever working of this that wouldn't permit the "pile-on"
> >> of additional entries of different (or even the same) roles on
> >> identical or near-identical atoms.
> >
> > They could be piled on; it would require each eclass to reset the
> > label for safety reasons though; same goes for ebuilds frankly (or the
> > PM would have to reset the context to build+run: each time through).
> >
> > Pardon if addressed elsewhere; this thread is a fucking mess...
> > ~harring
> >
> Correct me if I'm wrong, but couldn't the entire proposition could be
> implemented in an eclass, not needing the EAPI development cycle to be
> tied up with it.
> 
> All you need is something in bash that can parse DEPENDENCIES and
> populate *DEPEND , and the underlying guts could be done in
> practically any language without requiring PM specific
> implementations.

You've got it inverted; if any autopopulation is occuring, *DEPEND -> 
DEPENDENCIES is the sane form.

While it definitely *is* possible to render DEPENDENCIES down into 
depend/rdepend (after all, the PM has to do exactly this for 
resolution), that does /not/ mean doing it in bash is a good idea.

I'd really not want to try that using labels; using use conditionals 
('dep:run,build? ( targets )') is frankly a bit easier imo, but still; 
why do so unless one likes pain?  It doesn't actually gain us 
anything via missing the point of DEPENDENCIES.

The point of unified DEPENDENCIES var (regardless of the form) is 
thus:
1) ability to specify common deps once, w/out having to use 
intermediate vars/copy-pasting/etc.  Think COMMON_DEPEND, and this 
should make sense.

2) To shift to a form where adding new dependency targets is easy- 
whether it be sdepend, fdepend, tdepend, or hdepend (or 
ONE-RING-DEPEND to rule them all).  This actually is rather important; 
for the average 95% case, devs won't actually have to pay much 
attention to those vars; but for those of us a bit further out (cross 
compilation, heavy parallelization, etc) those depend forms are 
becoming increasingly painful in their absense.


Basically, having devs specify DEPENDENCIES in ebuilds, which then an 
eclass chunks out into DEPEND/RDEPEND misses the point of this; it's 
doable, it's just not particularly sane imo.

The other way around, having *DEPEND automatically be collapsed into 
DEPENDENCIES, however is very sane- it makes transition/compatibilty 
for devs bloody simple, while structuring it so we can do further 
enhancements.

~harring