On Sat, 15 Sep 2012 13:33:18 -0700 Brian Harring <[email protected]> wrote:
> On Sat, Sep 15, 2012 at 11:06:01PM +1200, Kent Fredric wrote: > > On 14 September 2012 10:17, Brian Harring <[email protected]> > > wrote: > > >> 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 > > > > > > > > > Sure, but at least this makes it a viable proof-of-concept without > > needing all the different PM's to implement the new spec first, and > > due to not being EAPI bound when done this way, means you can just > > do it and have it work both now and in the future. > > > > And because of this "experimental" nature, you don't have to do > > *ALL* the parsing in bash, you could make the eclass use some > > external code to parse it and spit it out, and simply have the > > eclass depend on that external program regardless. > > > > I agree that long term, a Unified DEPENDENCIES implementation is the > > way forward, but if you want to convince people, having something > > which has been demonstrated and tested in a real world setting goes > > a long way. > > Honestly, QA would be well within their rights to kick anyone who did > this, *hard* in the shins. > > I understand your notion- specifically proof of concept, show the > data, etc; I just think you've still got inverted, too focused on > trying to do it in bash. > > To demonstrate the gain of this, we basically take the existing > tree's deps, and re-render it into a unified DEPENDENCIES form. But in order to do this, we first have to decide exactly what kind of dependencies do we want to have. Then convert the tree to a separate-variable form with new dependencies. Then we can compare it with the DEPENDENCIES form and decide which one is better. -- Best regards, Michał Górny
signature.asc
Description: PGP signature
