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-08-2012, 01:02 AM
Patrick Lauer
 
Default Unified DEPENDENCIES concept

On 09/07/12 19:45, Ciaran McCreesh wrote:
> Since DEPENDENCIES hasn't been written up in a Gentoo-friendly manner,
> and since the Exherbo documentation doesn't seem to suffice to explain
> the idea here, here's some more details on the DEPENDENCIES proposal.
>
>
There's change, and there's progress.

This is change, just to have things change.

Like the /usr move, merging udev into some random package no one uses,
and some other things that people do to keep their fingers busy.


Can we please focus on progress instead?
 
Old 09-08-2012, 06:43 AM
Ciaran McCreesh
 
Default Unified DEPENDENCIES concept

On Fri, 07 Sep 2012 18:55:10 -0400
Michael Orlitzky <michael@orlitzky.com> wrote:
> I think that dependencies are ultimately not hierarchical

Situations like foo? ( bar? ( || ( a ( b c ) ) ) ) do happen, so any
new syntax would have to be able to deal with that.

--
Ciaran McCreesh
 
Old 09-08-2012, 07:27 AM
Michał Górny
 
Default Unified DEPENDENCIES concept

On Fri, 07 Sep 2012 18:55:10 -0400
Michael Orlitzky <michael@orlitzky.com> wrote:

> On 09/07/2012 07:45 AM, Ciaran McCreesh wrote:
> > Since DEPENDENCIES hasn't been written up in a Gentoo-friendly
> > manner, and since the Exherbo documentation doesn't seem to suffice
> > to explain the idea here, here's some more details on the
> > DEPENDENCIES proposal.
> >
>
> It seems to me that the problem this solves is just one of ontology.
> It's analogous to trying to stick files named "foo", "bar", "baz",
> etc. into directories named "depend", "rdepend", "hdepend", and so on.
>
> There are a few well-known ways to organize things in a hierarchy, and
> which one is most efficient depends on the categories and objects that
> you have. Given the way that most software is built (see:
> COMMON_DEPEND), I think DEPENDENCIES would work better than what we're
> doing now, but it also seems more complex.
>
> I think that dependencies are ultimately not hierarchical, and this
> can force duplication in DEPENDENCIES as well. Has anyone considered
> tagging the package atoms with a list of dependency types? For
> example,
>
> * foo/bar: ( build run host )
> * baz/one: baz? ( build )
> * baz/two, baz/three: baz? ( build run )
> ...
>
> This would eliminate duplication of the objects (package atoms) in
> favor of duplication of the categories (dependency types). Since the
> package atoms are what we really care about, I think the tradeoff is
> beneficial. Maintainers get to express each dependency exactly once.

This is nowhere near friendly to a developer...

--
Best regards,
Michał Górny
 
Old 09-08-2012, 01:01 PM
Michael Orlitzky
 
Default Unified DEPENDENCIES concept

On 09/08/2012 02:43 AM, Ciaran McCreesh wrote:
> On Fri, 07 Sep 2012 18:55:10 -0400 Michael Orlitzky
> <michael@orlitzky.com> wrote:
>> I think that dependencies are ultimately not hierarchical
>
> Situations like foo? ( bar? ( || ( a ( b c ) ) ) ) do happen, so
> any new syntax would have to be able to deal with that.
>

The deps in both cases are just a collection of atom/type pairs, so
anything possible in one must be possible in the other. I think this
means, if USE=bar, then we need either a or (b and c)? It could be
written,

|| (
a: bar? ( build run )
b,c: bar? ( build run )
)

Or if we wanted to make it even easier, allow the USE conditional at
the top level like we do now:

bar? ( || (
a: ( build run )
b,c: ( build run )
))

I'm just wondering if it wouldn't be nicer to think in terms of
package atoms instead of the dependency types. Right now, we've got
buckets named DEPEND, RDEPEND, etc. and we put the package atoms in
those buckets. The above syntax would make the package atoms the
buckets, and we would be putting the dependency types into the buckets
instead.
 
Old 09-09-2012, 03:32 AM
Matt Turner
 
Default Unified DEPENDENCIES concept

On Fri, Sep 7, 2012 at 4:45 AM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> Since DEPENDENCIES hasn't been written up in a Gentoo-friendly manner,
> and since the Exherbo documentation doesn't seem to suffice to explain
> the idea here, here's some more details on the DEPENDENCIES proposal.

I like this. It seems well planned and thought out and very flexible.
If I understand correctly paludis already supports this, so a working
implementation is already available which is clearly beneficial for a
proposal.

Thanks a lot, Ciaran, for writing this up.

Matt
 
Old 09-11-2012, 02:16 AM
Brian Harring
 
Default Unified DEPENDENCIES concept

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
 
Old 09-13-2012, 07:18 PM
Kent Fredric
 
Default Unified DEPENDENCIES concept

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.

[[[

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
 
Old 09-13-2012, 10:17 PM
Brian Harring
 
Default Unified DEPENDENCIES concept

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
 
Old 09-15-2012, 11:06 AM
Kent Fredric
 
Default Unified DEPENDENCIES concept

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.

--
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
 
Old 09-15-2012, 08:33 PM
Brian Harring
 
Default Unified DEPENDENCIES concept

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.

As for adding support to a PM, if we use the use conditional proposal
of mine, it's bloody simple- the PM already supports it, we just need
some minor USE_EXPAND adjustments.

~harring
 

Thread Tools




All times are GMT. The time now is 11:26 AM.

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