On Fri, Sep 14, 2012 at 07:18:54AM +1200, Kent Fredric wrote:
> 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.
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
