On 11 September 2012 14:16, Brian Harring <ferri...@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. [[[ inherit polydep; DEPENDENCIES=" Stuff Here. "; ]]] The only thing I know of that is limiting the above from being implemented that way is the lack of post-source eclass hooks, that is: currently you'd have to do either [[[ DEPENDENCIES="..." inherit polydep; ]]] or use a callback [[[ inherit polydep; DEPENDENCIES=" ... " polydeps; ]]] -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
