FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 09-15-2012, 10:03 PM
Michał Górny
 
Default Unified DEPENDENCIES concept

On Sat, 15 Sep 2012 13:33:18 -0700
Brian Harring <ferringb@gmail.com> wrote:

> On Sat, Sep 15, 2012 at 11:06:01PM +1200, Kent Fredric wrote:
> > On 14 September 2012 10:17, Brian Harring <ferringb@gmail.com>
> > 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
 

Thread Tools




All times are GMT. The time now is 10:44 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org