Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michał Górny]

On Sat, 15 Sep 2012 13:33:18 -0700
Brian Harring  wrote:

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

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Brian Harring]

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

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Kent Fredric]

On 14 September 2012 10:17, Brian Harring  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

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Brian Harring]

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

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Kent Fredric]

On 11 September 2012 14:16, Brian Harring  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

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Brian Harring]

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

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Matt Turner]

On Fri, Sep 7, 2012 at 4: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.

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

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michael Orlitzky]

On 09/08/2012 02:43 AM, Ciaran McCreesh wrote:
> On Fri, 07 Sep 2012 18:55:10 -0400 Michael Orlitzky
>  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.

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michał Górny]

On Fri, 07 Sep 2012 18:55:10 -0400
Michael Orlitzky  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


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

On Fri, 07 Sep 2012 18:55:10 -0400
Michael Orlitzky  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


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Patrick Lauer]

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?

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michael Orlitzky]

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.

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 07 Sep 2012 16:28:40 -0400
Ian Stakenvicius  wrote:
> >> - - the new DEPEND now will be used for things that are
> >> *currently* in RDEPEND and DEPEND (so that things will work) but
> >> are not actually run-time dependencies.  Said atoms will then be
> >> removed from RDEPEND (and not be included in the new HDEPEND
> >> either) as they aren't really supposed to be there in the first
> >> place.
> > 
> > I'm not entirely sure that there are more than a handful of very 
> > special cases that would be covered by the second point. Can
> > anyone provide examples?
> 
> Bug 263343 , the 'fontconfig' dep for some package i wasn't able to
> find easily

Do we have an explanation as to *why* fontconfig has to be on ROOT
here? Is it because $ROOT/var/cache/fontconfig needs to exist at build
time, but not at runtime? If so, is this better fixed by using a
temporary directory?

> Bug 317337 (original HDEPEND proposal) mentions the
> x11-proto/xcb-proto dep for libxcb (and i assume anything else
> depending on xcb-proto)

That's a BADEPEND.

- -- 
Ciaran McCreesh
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlBKW7cACgkQ96zL6DUtXhG0iQCfdYgzb5kFYE/fN6iTAEJriyuR
zxwAoJi0PvK7JZVqaltliyJFlCZARQRj
=Tzgv
-END PGP SIGNATURE-

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/09/12 04:14 PM, Ciaran McCreesh wrote:
> On Fri, 07 Sep 2012 16:08:53 -0400 Ian Stakenvicius
>  wrote:
>> Bringing it back to the issue it's solving:
> 
>> Afaict, for migration:
> 
>> - - DEPEND changes to HDEPEND
> 
> If we're going by Chromium, AFAICS they're only making this change
> when they find they actually need it to get the resolver to give
> "the right answer", and otherwise leaving DEPEND as-is. This
> strikes me as being heavily in Doing It Wrong territory.
> 
>> - - the new DEPEND now will be used for things that are
>> *currently* in RDEPEND and DEPEND (so that things will work) but
>> are not actually run-time dependencies.  Said atoms will then be
>> removed from RDEPEND (and not be included in the new HDEPEND
>> either) as they aren't really supposed to be there in the first
>> place.
> 
> I'm not entirely sure that there are more than a handful of very 
> special cases that would be covered by the second point. Can
> anyone provide examples?
> 

Bug 263343 , the 'fontconfig' dep for some package i wasn't able to
find easily

Bug 317337 (original HDEPEND proposal) mentions the
x11-proto/xcb-proto dep for libxcb (and i assume anything else
depending on xcb-proto)

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBKWPgACgkQ2ugaI38ACPDUFQEAhOF99mIqr/TXTOGFgdBdARg3
RSPlU8GQpxyEP2x9GPoA/07BSSTfoObc8COCTlpiC+RQP4zbUMwWODazNCszi/hx
=BMvQ
-END PGP SIGNATURE-

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

On Fri, 7 Sep 2012 22:07:30 +0200
Michał Górny  wrote:
> On Fri, 7 Sep 2012 20:25:58 +0100
> Ciaran McCreesh  wrote:
> > On Fri, 7 Sep 2012 21:21:42 +0200
> > Michał Górny  wrote:
> > > So... what is your issue in here, sir?
> > 
> > The issue is what Zac, Ian and I were discussing, before you jumped
> > in and started yelling. Repeating it for you:
> > 
> > We want to know, for dependencies that are in DEPEND and not
> > RDEPEND, whether or not most of them will become HDEPENDs, if
> > dependencies are being expressed properly. If that is the case,
> > then it makes more sense to introduce TDEPEND than HDEPEND.
> 
> The only person yelling here is you. I have politely asked a question,
> and then you come with your wisdom not answering it at all. And if you
> haven't noticed, my question was directed to Ian who -- unlike you --
> may be able to say something meaningful in the topic rather than
> diverging from it just to prove a random point only you know.

Ian and I are asking essentially the same question regarding the same
issue, and I believe you're the only interested person so far who has
had any difficulty understanding that. However, if hearing it from
someone other than me makes it easier for you to accept that there is
something to discuss, then you're welcome to pretend that everything
that I say from now on was written by someone other than me.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 07 Sep 2012 16:08:53 -0400
Ian Stakenvicius  wrote:
> Bringing it back to the issue it's solving:
> 
> Afaict, for migration:
> 
> - - DEPEND changes to HDEPEND

If we're going by Chromium, AFAICS they're only making this change when
they find they actually need it to get the resolver to give "the right
answer", and otherwise leaving DEPEND as-is. This strikes me as being
heavily in Doing It Wrong territory.

> - - the new DEPEND now will be used for things that are *currently* in
> RDEPEND and DEPEND (so that things will work) but are not actually
> run-time dependencies.  Said atoms will then be removed from RDEPEND
> (and not be included in the new HDEPEND either) as they aren't really
> supposed to be there in the first place.

I'm not entirely sure that there are more than a handful of very
special cases that would be covered by the second point. Can anyone
provide examples?

- -- 
Ciaran McCreesh
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlBKVbQACgkQ96zL6DUtXhHcUwCfdNq3MSMyYBAx19ImoOtWFMRM
l2UAoM6DfYJOCL4tLwZ3s6Jeh/6CzBCI
=FIrN
-END PGP SIGNATURE-

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/09/12 04:10 PM, Michał Górny wrote:
> On Fri, 7 Sep 2012 16:59:48 -0300 Alexis Ballier
>  wrote:
> 
>> On Fri, 7 Sep 2012 20:21:03 +0200 Michał Górny
>>  wrote:
>> 
>>> On Fri, 7 Sep 2012 14:40:25 -0300 Alexis Ballier
>>>  wrote:
>>> 
 On Fri, 7 Sep 2012 18:03:51 +0200 Michał Górny
  wrote:
 
> On Fri, 7 Sep 2012 12:46:41 -0300 Alexis Ballier
>  wrote:
> 
>> I actually do like the concept but I'm not sure we can
>> reach consensus about '*DEPEND vs DEPENDENCIES'; a
>> possibility to get people used to it could be to have two
>> parallel EAPIs, like 6 and 6-dependencies, where the
>> former will keep the old style and the latter use
>> DEPENDENCIES.
> 
> With eclasses supporting both of them? That's more than
> crazy.
 
 depstr=cat/foo
 
 case $EAPI in *-dependencies) DEPENDENCIES="build+run:
 $depstr";; *) DEPEND="$depstr" RDEPEND="$depstr";; esac
>>> 
>>> Yes, we have many eclasses where this is actually the only
>>> expected result. Maybe start with python.eclass, that should be
>>> quite an extreme example.
>>> 
>> 
>> Reference needed. You probably didn't even think more than 2
>> seconds before making this claim about python.eclass, because it
>> is not particularly hard.
> 
> Hmm, didn't it used to support having python as DEPEND only?
> 
> In any case, I'm thinking more of that line. Eclasses which
> sometimes add RDEP+DEP, sometimes DEP only, and sometimes do even
> crazier things.
> 

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.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBKVZkACgkQ2ugaI38ACPAdAwEAlGthSTR/jor93qpclC5Gl+Sl
82mjHm3ZObOC8Btf+SYA/AxaxCfHuWXoYKj5Ryo9CKna/7cdc1sUoV0fvacO9fja
=AoSy
-END PGP SIGNATURE-

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michał Górny]

On Fri, 7 Sep 2012 16:59:48 -0300
Alexis Ballier  wrote:

> On Fri, 7 Sep 2012 20:21:03 +0200
> Michał Górny  wrote:
> 
> > On Fri, 7 Sep 2012 14:40:25 -0300
> > Alexis Ballier  wrote:
> > 
> > > On Fri, 7 Sep 2012 18:03:51 +0200
> > > Michał Górny  wrote:
> > > 
> > > > On Fri, 7 Sep 2012 12:46:41 -0300
> > > > Alexis Ballier  wrote:
> > > > 
> > > > > I actually do like the concept but I'm not sure we can reach
> > > > > consensus about '*DEPEND vs DEPENDENCIES'; a possibility to
> > > > > get people used to it could be to have two parallel EAPIs,
> > > > > like 6 and 6-dependencies, where the former will keep the old
> > > > > style and the latter use DEPENDENCIES.
> > > > 
> > > > With eclasses supporting both of them? That's more than crazy.
> > > 
> > > depstr=cat/foo
> > > 
> > > case $EAPI in
> > >  *-dependencies) DEPENDENCIES="build+run: $depstr";;
> > >  *) DEPEND="$depstr"
> > > RDEPEND="$depstr";;
> > > esac
> > 
> > Yes, we have many eclasses where this is actually the only expected
> > result. Maybe start with python.eclass, that should be quite an
> > extreme example.
> > 
> 
> Reference needed. You probably didn't even think more than 2 seconds
> before making this claim about python.eclass, because it is not
> particularly hard.

Hmm, didn't it used to support having python as DEPEND only?

In any case, I'm thinking more of that line. Eclasses which sometimes
add RDEP+DEP, sometimes DEP only, and sometimes do even crazier things.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/09/12 02:52 PM, Ciaran McCreesh wrote:
> On Fri, 7 Sep 2012 20:46:48 +0200 Michał Górny 
> wrote:
>> Now, let me remind you because you probably fail to know the
>> world outside your dreamworld:
>> 
>> (with HDEPEND/DEPEND) generally mean that we would need to 
>> s/DEPEND/HDEPEND/ for the vast majority of ebuilds (ie all the 
>> trivial ones)?
>> 
>> That does effectively refer to the common depends as well. You
>> know, in the real world where there is no magical variables which
>> do miracles behind your back.
> 
> Uhm, no, it doesn't. Things in both DEPEND and RDEPEND are an 
> *entirely* different case when it comes to destinations, since
> RDEPEND goes to ROOT.
> 
> The distinction between DEPEND and HDEPEND is relevant only for 
> dependencies that are not also in RDEPEND.
> 

Bringing it back to the issue it's solving:

Afaict, for migration:

- - DEPEND changes to HDEPEND
- - the new DEPEND now will be used for things that are *currently* in
RDEPEND and DEPEND (so that things will work) but are not actually
run-time dependencies.  Said atoms will then be removed from RDEPEND
(and not be included in the new HDEPEND either) as they aren't really
supposed to be there in the first place.

Right?

(Note, I have no idea how this will play with PDEPEND but maybe some
of the current circular dependencies will also disappear?)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBKVFUACgkQ2ugaI38ACPCcbwEAr2/+lQ70jPJ0AWp+hGQUo6YG
dFxOJPOoRpBnVlipvnoBAJgQmfB5fqK6lNQB5iJghQYhqRk5KCN4SZe7/lltRviA
=xDo8
-END PGP SIGNATURE-

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michał Górny]

On Fri, 7 Sep 2012 20:25:58 +0100
Ciaran McCreesh  wrote:

> On Fri, 7 Sep 2012 21:21:42 +0200
> Michał Górny  wrote:
> > So... what is your issue in here, sir?
> 
> The issue is what Zac, Ian and I were discussing, before you jumped in
> and started yelling. Repeating it for you:
> 
> We want to know, for dependencies that are in DEPEND and not RDEPEND,
> whether or not most of them will become HDEPENDs, if dependencies are
> being expressed properly. If that is the case, then it makes more
> sense to introduce TDEPEND than HDEPEND.

The only person yelling here is you. I have politely asked a question,
and then you come with your wisdom not answering it at all. And if you
haven't noticed, my question was directed to Ian who -- unlike you --
may be able to say something meaningful in the topic rather than
diverging from it just to prove a random point only you know.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Alexis Ballier]

On Fri, 7 Sep 2012 20:21:03 +0200
Michał Górny  wrote:

> On Fri, 7 Sep 2012 14:40:25 -0300
> Alexis Ballier  wrote:
> 
> > On Fri, 7 Sep 2012 18:03:51 +0200
> > Michał Górny  wrote:
> > 
> > > On Fri, 7 Sep 2012 12:46:41 -0300
> > > Alexis Ballier  wrote:
> > > 
> > > > I actually do like the concept but I'm not sure we can reach
> > > > consensus about '*DEPEND vs DEPENDENCIES'; a possibility to get
> > > > people used to it could be to have two parallel EAPIs, like 6
> > > > and 6-dependencies, where the former will keep the old style
> > > > and the latter use DEPENDENCIES.
> > > 
> > > With eclasses supporting both of them? That's more than crazy.
> > 
> > depstr=cat/foo
> > 
> > case $EAPI in
> >  *-dependencies) DEPENDENCIES="build+run: $depstr";;
> >  *) DEPEND="$depstr"
> > RDEPEND="$depstr";;
> > esac
> 
> Yes, we have many eclasses where this is actually the only expected
> result. Maybe start with python.eclass, that should be quite an
> extreme example.
> 

Reference needed. You probably didn't even think more than 2 seconds
before making this claim about python.eclass, because it is not
particularly hard.

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/09/12 02:46 PM, Michał Górny wrote:
> On Fri, 7 Sep 2012 19:31:16 +0100 Ciaran McCreesh
>  wrote:
> 
>> On Fri, 7 Sep 2012 20:23:23 +0200 Michał Górny
>>  wrote:
>>> I can't agree unless I am missing something. Doesn't the
>>> majority of ebuilds actually require most of DEPEND (well, the
>>> part common with RDEPEND) to be installed on the target? I'm
>>> thinking of the shared libraries mostly.
>> 
>> "The part common with RDEPEND" is a different issue. We're
>> talking about what the usual thing to do is for dependencies that
>> are in DEPEND but not RDEPEND. A typical example here is a binary
>> that is executed as part of the build process.
> 
> Thanks for keeping me on the topic.
> 
> Now, let me remind you because you probably fail to know the world 
> outside your dreamworld:
> 
> (with HDEPEND/DEPEND) generally mean that we would need to 
> s/DEPEND/HDEPEND/ for the vast majority of ebuilds (ie all the
> trivial ones)?
> 
> That does effectively refer to the common depends as well. You
> know, in the real world where there is no magical variables which
> do miracles behind your back.
> 

RDEPEND is defined in an earlier post (by Zac i think?) as target
build+run dependencies; there are very few actual target build-only
dependencies (ie, deps that need to be installed on the target and
don't need to be installed on the host, and don't need to be on the
target after build time).  As such, HDEPEND since it means build-host
build-time deps will still need to have these common dependencies
specified but that doesn't have anything to do with the target's
requirements, which right now are already entirely covered by RDEPEND
(and not DEPEND) at all.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBKTg0ACgkQ2ugaI38ACPBZJwD9E9MT2ZVsKtY+VujuMYjhi5EC
B0RfyRnpXHu4JraBh+0A/014AWaOO3x70axEfdzTFbygRepDe6LWPqFy71nxBC3v
=7hsL
-END PGP SIGNATURE-

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

On Fri, 7 Sep 2012 21:21:42 +0200
Michał Górny  wrote:
> So... what is your issue in here, sir?

The issue is what Zac, Ian and I were discussing, before you jumped in
and started yelling. Repeating it for you:

We want to know, for dependencies that are in DEPEND and not RDEPEND,
whether or not most of them will become HDEPENDs, if dependencies are
being expressed properly. If that is the case, then it makes more sense
to introduce TDEPEND than HDEPEND.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michał Górny]

On Fri, 7 Sep 2012 20:13:19 +0100
Ciaran McCreesh  wrote:

> On Fri, 7 Sep 2012 21:11:22 +0200
> Michał Górny  wrote:
> > On Fri, 7 Sep 2012 19:52:05 +0100
> > Ciaran McCreesh  wrote:
> > > On Fri, 7 Sep 2012 20:46:48 +0200
> > > Michał Górny  wrote:
> > > > Now, let me remind you because you probably fail to know the
> > > > world outside your dreamworld:
> > > > 
> > > >   (with HDEPEND/DEPEND) generally mean that we would need to
> > > >   s/DEPEND/HDEPEND/ for the vast majority of ebuilds (ie all the
> > > > trivial ones)?
> > > > 
> > > > That does effectively refer to the common depends as well. You
> > > > know, in the real world where there is no magical variables
> > > > which do miracles behind your back.
> > > 
> > > Uhm, no, it doesn't. Things in both DEPEND and RDEPEND are an
> > > *entirely* different case when it comes to destinations, since
> > > RDEPEND goes to ROOT.
> > 
> > And? RDEPEND isn't required to be merged before building the
> > package.
> 
> I repeat: "things in both DEPEND and RDEPEND".
> 
> I also repeat: HDEPEND is relevant only to things that are in DEPEND
> and not RDEPEND.

So... what is your issue in here, sir?

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

On Fri, 7 Sep 2012 21:11:22 +0200
Michał Górny  wrote:
> On Fri, 7 Sep 2012 19:52:05 +0100
> Ciaran McCreesh  wrote:
> > On Fri, 7 Sep 2012 20:46:48 +0200
> > Michał Górny  wrote:
> > > Now, let me remind you because you probably fail to know the world
> > > outside your dreamworld:
> > > 
> > >   (with HDEPEND/DEPEND) generally mean that we would need to
> > >   s/DEPEND/HDEPEND/ for the vast majority of ebuilds (ie all the
> > > trivial ones)?
> > > 
> > > That does effectively refer to the common depends as well. You
> > > know, in the real world where there is no magical variables which
> > > do miracles behind your back.
> > 
> > Uhm, no, it doesn't. Things in both DEPEND and RDEPEND are an
> > *entirely* different case when it comes to destinations, since
> > RDEPEND goes to ROOT.
> 
> And? RDEPEND isn't required to be merged before building the package.

I repeat: "things in both DEPEND and RDEPEND".

I also repeat: HDEPEND is relevant only to things that are in DEPEND
and not RDEPEND.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michał Górny]

On Fri, 7 Sep 2012 19:52:05 +0100
Ciaran McCreesh  wrote:

> On Fri, 7 Sep 2012 20:46:48 +0200
> Michał Górny  wrote:
> > Now, let me remind you because you probably fail to know the world
> > outside your dreamworld:
> > 
> >   (with HDEPEND/DEPEND) generally mean that we would need to
> >   s/DEPEND/HDEPEND/ for the vast majority of ebuilds (ie all the
> > trivial ones)?
> > 
> > That does effectively refer to the common depends as well. You know,
> > in the real world where there is no magical variables which do
> > miracles behind your back.
> 
> Uhm, no, it doesn't. Things in both DEPEND and RDEPEND are an
> *entirely* different case when it comes to destinations, since RDEPEND
> goes to ROOT.

And? RDEPEND isn't required to be merged before building the package.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

On Fri, 7 Sep 2012 20:46:48 +0200
Michał Górny  wrote:
> Now, let me remind you because you probably fail to know the world
> outside your dreamworld:
> 
>   (with HDEPEND/DEPEND) generally mean that we would need to
>   s/DEPEND/HDEPEND/ for the vast majority of ebuilds (ie all the
> trivial ones)?
> 
> That does effectively refer to the common depends as well. You know,
> in the real world where there is no magical variables which do
> miracles behind your back.

Uhm, no, it doesn't. Things in both DEPEND and RDEPEND are an
*entirely* different case when it comes to destinations, since RDEPEND
goes to ROOT.

The distinction between DEPEND and HDEPEND is relevant only for
dependencies that are not also in RDEPEND.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michał Górny]

On Fri, 7 Sep 2012 19:31:16 +0100
Ciaran McCreesh  wrote:

> On Fri, 7 Sep 2012 20:23:23 +0200
> Michał Górny  wrote:
> > I can't agree unless I am missing something. Doesn't the majority of
> > ebuilds actually require most of DEPEND (well, the part common with
> > RDEPEND) to be installed on the target? I'm thinking of the shared
> > libraries mostly.
> 
> "The part common with RDEPEND" is a different issue. We're talking
> about what the usual thing to do is for dependencies that are in
> DEPEND but not RDEPEND. A typical example here is a binary that is
> executed as part of the build process.

Thanks for keeping me on the topic.

Now, let me remind you because you probably fail to know the world
outside your dreamworld:

  (with HDEPEND/DEPEND) generally mean that we would need to
  s/DEPEND/HDEPEND/ for the vast majority of ebuilds (ie all the trivial
  ones)?

That does effectively refer to the common depends as well. You know, in
the real world where there is no magical variables which do miracles
behind your back.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

On Fri, 7 Sep 2012 20:23:23 +0200
Michał Górny  wrote:
> I can't agree unless I am missing something. Doesn't the majority of
> ebuilds actually require most of DEPEND (well, the part common with
> RDEPEND) to be installed on the target? I'm thinking of the shared
> libraries mostly.

"The part common with RDEPEND" is a different issue. We're talking
about what the usual thing to do is for dependencies that are in
DEPEND but not RDEPEND. A typical example here is a binary that is
executed as part of the build process.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 07 Sep 2012 11:18:28 -0700
Zac Medico  wrote:
> In the linked chromium-os-dev discussion, the consensus seemed to be
> that migrating deps from DEPEND to HDEPEND would result in fewer
> overall changes than migrating deps from DEPEND to TDEPEND. For this
> reason, the dominant preference was to go with HDEPEND.

They're looking at "minimum number of changes to make it appear to
work", not "minimum number of changes to express dependencies
correctly".

- -- 
Ciaran McCreesh
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlBKO44ACgkQ96zL6DUtXhHGDwCgi66mZCVH0UWdB8yfJxl8lcuR
QPkAnRgziWGLpMbJ1i92CXjRJ1Q2tWzJ
=S+jv
-END PGP SIGNATURE-

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Zac Medico]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/07/2012 11:18 AM, Zac Medico wrote:
> On 09/07/2012 10:58 AM, Ian Stakenvicius wrote:
>> On 07/09/12 01:40 PM, Zac Medico wrote:
>>> On 09/07/2012 10:02 AM, Ian Stakenvicius wrote:
 On 07/09/12 12:58 PM, Ciaran McCreesh wrote:
> On Fri, 07 Sep 2012 09:53:46 -0700 Zac Medico 
>  wrote:
>> If you're insinuating that Portage may not have a 
>> "fully-ROOT-and-/-aware resolver", then I can assure you
>>  that this is not a problem.
 
> In that case, why do we need HDEPEND at all?
 
 
 We don't, actually; HDEPEND is essentially DEPEND.  what we 
 need is TDEPEND.
> 
>>> We could do either one (or do both, and get rid of DEPEND). In
>>>  discussions on the chromium-os-dev list [1] (people who could 
>>> have been using HDEPEND for years now), the dominant
>>> preference was to use HDEPEND since they felt that it would
>>> require the least amount of adjustment to existing DEPEND
>>> settings.
> 
>>> [1] 
>>> https://groups.google.com/a/chromium.org/forum/?fromgroups=#!topic/chromium-os-dev/yVAcpfZHrOE
>
>>> 
>>> 
> 
>> Thanks
> 
>> for clarifying this; after reading through the bug I wasn't sure
>> if the recommendation was to add HDEPEND only or to deprecate
>> DEPEND entirely for HDEPEND/TDEPEND.
> 
>> Just to clarify the work involved in converting to this; since 
>> DEPEND on EAPI<=4 is essentially HDEPEND , wouldn't migration to 
>> the new EAPI (with HDEPEND/DEPEND) generally mean that we would 
>> need to s/DEPEND/HDEPEND/ for the vast majority of ebuilds (ie
>> all the trivial ones)?
> 
> In the linked chromium-os-dev discussion, the consensus seemed to
> be that migrating deps from DEPEND to HDEPEND would result in
> fewer overall changes than migrating deps from DEPEND to TDEPEND.
> For this reason, the dominant preference was to go with HDEPEND.

Also, if the HDEPEND proposal is accepted, then I would recommend to
treat the migration of dependencies to HDEPEND as entirely optional.
This is similar to the approach that we took with the introduction of
prefix support in EAPI 3, where EAPI 3 ebuilds were not obligated to
support prefix.
- -- 
Thanks,
Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBKO6cACgkQ/ejvha5XGaOTVwCfUTyG5yHC6PIoBpsUhWvD874U
bBcAmwfhVLRWRwDBWfI2LvFTdXUY0q7y
=0a/L
-END PGP SIGNATURE-

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michał Górny]

On Fri, 07 Sep 2012 13:58:00 -0400
Ian Stakenvicius  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 07/09/12 01:40 PM, Zac Medico wrote:
> > On 09/07/2012 10:02 AM, Ian Stakenvicius wrote:
> >> On 07/09/12 12:58 PM, Ciaran McCreesh wrote:
> >>> On Fri, 07 Sep 2012 09:53:46 -0700 Zac Medico
> >>>  wrote:
>  If you're insinuating that Portage may not have a 
>  "fully-ROOT-and-/-aware resolver", then I can assure you
>  that this is not a problem.
> >> 
> >>> In that case, why do we need HDEPEND at all?
> >> 
> >> 
> >> We don't, actually; HDEPEND is essentially DEPEND.  what we need
> >> is TDEPEND.
> > 
> > We could do either one (or do both, and get rid of DEPEND). In 
> > discussions on the chromium-os-dev list [1] (people who could have
> > been using HDEPEND for years now), the dominant preference was to
> > use HDEPEND since they felt that it would require the least amount
> > of adjustment to existing DEPEND settings.
> > 
> > [1] 
> > https://groups.google.com/a/chromium.org/forum/?fromgroups=#!topic/chromium-os-dev/yVAcpfZHrOE
> 
> 
> Thanks
> > 
> for clarifying this; after reading through the bug I wasn't
> sure if the recommendation was to add HDEPEND only or to deprecate
> DEPEND entirely for HDEPEND/TDEPEND.
> 
> Just to clarify the work involved in converting to this; since DEPEND
> on EAPI<=4 is essentially HDEPEND , wouldn't migration to the new EAPI
> (with HDEPEND/DEPEND) generally mean that we would need to
> s/DEPEND/HDEPEND/ for the vast majority of ebuilds (ie all the trivial
> ones)?

I can't agree unless I am missing something. Doesn't the majority of
ebuilds actually require most of DEPEND (well, the part common with
RDEPEND) to be installed on the target? I'm thinking of the shared
libraries mostly.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michał Górny]

On Fri, 7 Sep 2012 14:40:25 -0300
Alexis Ballier  wrote:

> On Fri, 7 Sep 2012 18:03:51 +0200
> Michał Górny  wrote:
> 
> > On Fri, 7 Sep 2012 12:46:41 -0300
> > Alexis Ballier  wrote:
> > 
> > > I actually do like the concept but I'm not sure we can reach
> > > consensus about '*DEPEND vs DEPENDENCIES'; a possibility to get
> > > people used to it could be to have two parallel EAPIs, like 6 and
> > > 6-dependencies, where the former will keep the old style and the
> > > latter use DEPENDENCIES.
> > 
> > With eclasses supporting both of them? That's more than crazy.
> 
> depstr=cat/foo
> 
> case $EAPI in
>  *-dependencies) DEPENDENCIES="build+run: $depstr";;
>  *) DEPEND="$depstr"
> RDEPEND="$depstr";;
> esac

Yes, we have many eclasses where this is actually the only expected
result. Maybe start with python.eclass, that should be quite an extreme
example.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Zac Medico]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/07/2012 10:58 AM, Ian Stakenvicius wrote:
> On 07/09/12 01:40 PM, Zac Medico wrote:
>> On 09/07/2012 10:02 AM, Ian Stakenvicius wrote:
>>> On 07/09/12 12:58 PM, Ciaran McCreesh wrote:
 On Fri, 07 Sep 2012 09:53:46 -0700 Zac Medico 
  wrote:
> If you're insinuating that Portage may not have a 
> "fully-ROOT-and-/-aware resolver", then I can assure you 
> that this is not a problem.
>>> 
 In that case, why do we need HDEPEND at all?
>>> 
>>> 
>>> We don't, actually; HDEPEND is essentially DEPEND.  what we
>>> need is TDEPEND.
> 
>> We could do either one (or do both, and get rid of DEPEND). In 
>> discussions on the chromium-os-dev list [1] (people who could
>> have been using HDEPEND for years now), the dominant preference
>> was to use HDEPEND since they felt that it would require the
>> least amount of adjustment to existing DEPEND settings.
> 
>> [1] 
>> https://groups.google.com/a/chromium.org/forum/?fromgroups=#!topic/chromium-os-dev/yVAcpfZHrOE
>
>> 
> 
> Thanks
> 
> for clarifying this; after reading through the bug I wasn't sure if
> the recommendation was to add HDEPEND only or to deprecate DEPEND
> entirely for HDEPEND/TDEPEND.
> 
> Just to clarify the work involved in converting to this; since
> DEPEND on EAPI<=4 is essentially HDEPEND , wouldn't migration to
> the new EAPI (with HDEPEND/DEPEND) generally mean that we would
> need to s/DEPEND/HDEPEND/ for the vast majority of ebuilds (ie all
> the trivial ones)?

In the linked chromium-os-dev discussion, the consensus seemed to be
that migrating deps from DEPEND to HDEPEND would result in fewer
overall changes than migrating deps from DEPEND to TDEPEND. For this
reason, the dominant preference was to go with HDEPEND.
- -- 
Thanks,
Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBKOnQACgkQ/ejvha5XGaNguwCg01LvwyvD2AcUG2sTMdTakjuH
P4EAniQQpndputGCSLTcRB2VeZcfFhIj
=5idF
-END PGP SIGNATURE-

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/09/12 01:40 PM, Zac Medico wrote:
> On 09/07/2012 10:02 AM, Ian Stakenvicius wrote:
>> On 07/09/12 12:58 PM, Ciaran McCreesh wrote:
>>> On Fri, 07 Sep 2012 09:53:46 -0700 Zac Medico
>>>  wrote:
 If you're insinuating that Portage may not have a 
 "fully-ROOT-and-/-aware resolver", then I can assure you
 that this is not a problem.
>> 
>>> In that case, why do we need HDEPEND at all?
>> 
>> 
>> We don't, actually; HDEPEND is essentially DEPEND.  what we need
>> is TDEPEND.
> 
> We could do either one (or do both, and get rid of DEPEND). In 
> discussions on the chromium-os-dev list [1] (people who could have
> been using HDEPEND for years now), the dominant preference was to
> use HDEPEND since they felt that it would require the least amount
> of adjustment to existing DEPEND settings.
> 
> [1] 
> https://groups.google.com/a/chromium.org/forum/?fromgroups=#!topic/chromium-os-dev/yVAcpfZHrOE


Thanks
> 
for clarifying this; after reading through the bug I wasn't
sure if the recommendation was to add HDEPEND only or to deprecate
DEPEND entirely for HDEPEND/TDEPEND.

Just to clarify the work involved in converting to this; since DEPEND
on EAPI<=4 is essentially HDEPEND , wouldn't migration to the new EAPI
(with HDEPEND/DEPEND) generally mean that we would need to
s/DEPEND/HDEPEND/ for the vast majority of ebuilds (ie all the trivial
ones)?

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBKNagACgkQ2ugaI38ACPD7fAD+ItO84yPGTtG5G9aY0nJvTheA
QP4CRV8euHOUeCt1CGsBAK0DbpLXnARHd6lHYCAnuihezRRYr8rO8xw7kIKmlx/U
=DkxI
-END PGP SIGNATURE-

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Zac Medico]

On 09/07/2012 10:02 AM, Ian Stakenvicius wrote:
> On 07/09/12 12:58 PM, Ciaran McCreesh wrote:
>> On Fri, 07 Sep 2012 09:53:46 -0700 Zac Medico 
>> wrote:
>>> If you're insinuating that Portage may not have a 
>>> "fully-ROOT-and-/-aware resolver", then I can assure you that
>>> this is not a problem.
> 
>> In that case, why do we need HDEPEND at all?
> 
> 
> We don't, actually; HDEPEND is essentially DEPEND.  what we need is
> TDEPEND.

We could do either one (or do both, and get rid of DEPEND). In
discussions on the chromium-os-dev list [1] (people who could have been
using HDEPEND for years now), the dominant preference was to use HDEPEND
since they felt that it would require the least amount of adjustment to
existing DEPEND settings.

[1]
https://groups.google.com/a/chromium.org/forum/?fromgroups=#!topic/chromium-os-dev/yVAcpfZHrOE
-- 
Thanks,
Zac

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Alexis Ballier]

On Fri, 7 Sep 2012 18:03:51 +0200
Michał Górny  wrote:

> On Fri, 7 Sep 2012 12:46:41 -0300
> Alexis Ballier  wrote:
> 
> > I actually do like the concept but I'm not sure we can reach
> > consensus about '*DEPEND vs DEPENDENCIES'; a possibility to get
> > people used to it could be to have two parallel EAPIs, like 6 and
> > 6-dependencies, where the former will keep the old style and the
> > latter use DEPENDENCIES.
> 
> With eclasses supporting both of them? That's more than crazy.

depstr=cat/foo

case $EAPI in
 *-dependencies) DEPENDENCIES="build+run: $depstr";;
 *) DEPEND="$depstr"
RDEPEND="$depstr";;
esac


Yes, eclasses supporting more than one EAPI is crazy and we should
create a new eclass for every EAPI :)


> > After some time has passed, it could be decided to kill the less
> > useful one, say in EAPI 8, and get only one 'latest' EAPI again.
> > This decision doesn't need to be left only to the council, but
> > since it affects everyone it could be a vote from all the dev
> > community.
> 
> Why the dev community only? We have many active contributors who
> aren't devs and who work hard with ebuilds. It's *their* time which
> will be wasted on rewriting dependencies into new form, not yours.

It seems we have a different definition of 'dev community'. That's true
we have well established voting procedures for gentoo devs or foundation
members, but feel free to propose one for the rest of contributors.

> > There is also the possibility that a consensus will never be reached
> > and that the two styles will have to live forever, but after all,
> > the EAPI concept is made for this.
> 
> I believe the correct concept is 'fork'. And that's what Exherbo did.

An EAPI is a fork of the ebuild API already. Exherbo is not a fork as
far as I know, or at least not more than Gentoo is a Redhat fork
because it can process rpm's.

A.

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Zac Medico]

On 09/07/2012 09:58 AM, Ciaran McCreesh wrote:
> On Fri, 07 Sep 2012 09:53:46 -0700
> Zac Medico  wrote:
>> If you're insinuating that Portage may not have a
>> "fully-ROOT-and-/-aware resolver", then I can assure you that this is
>> not a problem.
> 
> In that case, why do we need HDEPEND at all?

With existing EAPIs, it's possible to use DEPEND for host buildtime-only
deps, RDEPEND for target build+run deps, and PDEPEND for target
runtime-only deps. However, there's no way to to specify buildtime-only
target deps (that aren't needed at runtime). The HDEPEND proposal
involves solves this by using HDEPEND for host buildtime-only deps, and
DEPEND for target buildtime-only deps.
-- 
Thanks,
Zac

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/09/12 12:58 PM, Ciaran McCreesh wrote:
> On Fri, 07 Sep 2012 09:53:46 -0700 Zac Medico 
> wrote:
>> If you're insinuating that Portage may not have a 
>> "fully-ROOT-and-/-aware resolver", then I can assure you that
>> this is not a problem.
> 
> In that case, why do we need HDEPEND at all?
> 

We don't, actually; HDEPEND is essentially DEPEND.  what we need is
TDEPEND.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBKKKgACgkQ2ugaI38ACPBHFgD/Y7drSHcrEnjNuQZ2bbkLgXPh
6g1KmT4u2xljTR0WergA/jc80lQ2Zy7L3CI2Hn9kyy6cmyZ7yTHJHn5ysdAZkTbS
=kdVT
-END PGP SIGNATURE-

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

On Fri, 07 Sep 2012 09:53:46 -0700
Zac Medico  wrote:
> If you're insinuating that Portage may not have a
> "fully-ROOT-and-/-aware resolver", then I can assure you that this is
> not a problem.

In that case, why do we need HDEPEND at all?

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Zac Medico]

On 09/07/2012 09:10 AM, Ciaran McCreesh wrote:
> On Fri, 7 Sep 2012 12:46:41 -0300
> Alexis Ballier  wrote:
>> For example, what is the HDEPEND equivalent for DEPENDENCIES ? exherbo
>> documentation doesn't seem to mention an equivalent label.
> 
> DEPENDENCIES is essentially independent of what label names we
> introduce. I get the impression Gentoo will be bikeshedding, er, I mean
> selecting shorter names for some of the labels than what Exherbo is
> using. So HDEPEND could be 'host' if you like.
> 
> In any case, the reason you don't see a 'host' label on Exherbo is
> because it's called 'build'. Exherbo's taken a more comprehensive
> approach to handling ROOT-related dependencies -- dependency resolution
> for ROOT!=/ still uses / for satisfying not-purely-runtimeish
> dependencies, and then has a way of locking versions on / to versions
> in ROOT. It does rely upon having a fully-ROOT-and-/-aware resolver,
> though, so it may not be suitable for Gentoo.

If you're insinuating that Portage may not have a
"fully-ROOT-and-/-aware resolver", then I can assure you that this is
not a problem. The only reason that Portage currently doesn't have "a
way of locking versions on / to versions in ROOT" is that none of the
existing EAPIs have a way to express this kind of dependency constraint.
-- 
Thanks,
Zacd

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

On Fri, 07 Sep 2012 18:40:47 +0200
""Paweł Hajdan, Jr.""  wrote:
> Also, requiring a rewrite of all existing ebuilds doesn't sound like a
> good idea. I think this should be designed not to require a rewrite,
> and then the concern about wasted time disappears.

Uh, there is no "rewriting all existing ebuilds" anywhere. I've no idea
where you got that from...

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michał Górny]

On Fri, 07 Sep 2012 18:12:08 +0200
""Paweł Hajdan, Jr.""  wrote:

> On 9/7/12 5:46 PM, Alexis Ballier wrote:
> > I actually do like the concept but I'm not sure we can reach
> > consensus about '*DEPEND vs DEPENDENCIES'
> 
> I also like at least significant parts of the DEPENDENCIES concept,
> especially when we start adding more dep variables like HDEPEND.
> 
> My understanding is that COMMON_DEPEND can be easily and uniformly
> expressed as build+run.
> 
> Do we have some list of pros and cons, so that the discussion can be
> more focused?

There's one on the wiki but I'm not sure if it's up-to-date now. I made
it on top of the previous thread.

http://wiki.gentoo.org/wiki/Future_EAPI/DEPENDENCIES_variable

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Paweł Hajdan, Jr.]

On 9/7/12 6:03 PM, Michał Górny wrote:
> Why the dev community only? We have many active contributors who aren't
> devs and who work hard with ebuilds. It's *their* time which will be
> wasted on rewriting dependencies into new form, not yours.

Should those contributors also vote? Do they have any formal status? Do
we have established procedures for that case?

By the way, for everyone else, there is a forums thread about this topic
here:


I guess the contributors follow gentoo-dev, so they at least can voice
their concerns, if any.

Also, requiring a rewrite of all existing ebuilds doesn't sound like a
good idea. I think this should be designed not to require a rewrite, and
then the concern about wasted time disappears.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

On Fri, 7 Sep 2012 12:28:31 -0400
Michael Mol  wrote:
> An intermediate form of that might be useful for auditing the tree and
> finding packages which aren't expressing, e.g. RDEPENDS, but probably
> should.

RDEPEND=DEPEND was removed in EAPI 4, if that's what you mean.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michael Mol]

On Fri, Sep 7, 2012 at 12:11 PM, Ian Stakenvicius  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 07/09/12 12:03 PM, Michał Górny wrote:
>> On Fri, 7 Sep 2012 12:46:41 -0300 Alexis Ballier
>>  wrote:
>>
>>> I actually do like the concept but I'm not sure we can reach
>>> consensus about '*DEPEND vs DEPENDENCIES'; a possibility to get
>>> people used to it could be to have two parallel EAPIs, like 6 and
>>> 6-dependencies, where the former will keep the old style and the
>>> latter use DEPENDENCIES.
>>
>> With eclasses supporting both of them? That's more than crazy.
>>
>
> By the time EAPI=6* would happen we should have a git tree so we'd
> just fork the tree for EAPI=6-dependencies.  :)
>
> A change like this would *NEED* a long-term test phase with a lot of
> developer participation, so if we were to consider it we'd need to
> fork the tree and implement/maintain it in parallel to main tree
> maintenance, imo.  A translation script could probably also be used to
> convert *DEPEND into DEPENDENCIES automatically for any packages that
> dev's aren't manually managing...
>
> ...But I digress; we're nowhere near doing this yet.

An intermediate form of that might be useful for auditing the tree and
finding packages which aren't expressing, e.g. RDEPENDS, but probably
should.

-- 
:wq

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

On Fri, 7 Sep 2012 12:46:41 -0300
Alexis Ballier  wrote:
> For example, what is the HDEPEND equivalent for DEPENDENCIES ? exherbo
> documentation doesn't seem to mention an equivalent label.

DEPENDENCIES is essentially independent of what label names we
introduce. I get the impression Gentoo will be bikeshedding, er, I mean
selecting shorter names for some of the labels than what Exherbo is
using. So HDEPEND could be 'host' if you like.

In any case, the reason you don't see a 'host' label on Exherbo is
because it's called 'build'. Exherbo's taken a more comprehensive
approach to handling ROOT-related dependencies -- dependency resolution
for ROOT!=/ still uses / for satisfying not-purely-runtimeish
dependencies, and then has a way of locking versions on / to versions
in ROOT. It does rely upon having a fully-ROOT-and-/-aware resolver,
though, so it may not be suitable for Gentoo.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Paweł Hajdan, Jr.]

On 9/7/12 5:46 PM, Alexis Ballier wrote:
> I actually do like the concept but I'm not sure we can reach consensus
> about '*DEPEND vs DEPENDENCIES'

I also like at least significant parts of the DEPENDENCIES concept,
especially when we start adding more dep variables like HDEPEND.

My understanding is that COMMON_DEPEND can be easily and uniformly
expressed as build+run.

Do we have some list of pros and cons, so that the discussion can be
more focused?

> a possibility to get people used to it
> could be to have two parallel EAPIs, like 6 and 6-dependencies, where
> the former will keep the old style and the latter use DEPENDENCIES.

How about just allowing older style DEPEND/RDEPEND, but not both
DEPEND/RDEPEND and DEPENDENCIES in the same ebuild? Note that this may
interact with eclasses (which is also true for above idea I think).



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/09/12 12:03 PM, Michał Górny wrote:
> On Fri, 7 Sep 2012 12:46:41 -0300 Alexis Ballier
>  wrote:
> 
>> I actually do like the concept but I'm not sure we can reach
>> consensus about '*DEPEND vs DEPENDENCIES'; a possibility to get
>> people used to it could be to have two parallel EAPIs, like 6 and
>> 6-dependencies, where the former will keep the old style and the
>> latter use DEPENDENCIES.
> 
> With eclasses supporting both of them? That's more than crazy.
> 

By the time EAPI=6* would happen we should have a git tree so we'd
just fork the tree for EAPI=6-dependencies.  :)

A change like this would *NEED* a long-term test phase with a lot of
developer participation, so if we were to consider it we'd need to
fork the tree and implement/maintain it in parallel to main tree
maintenance, imo.  A translation script could probably also be used to
convert *DEPEND into DEPENDENCIES automatically for any packages that
dev's aren't manually managing...

...But I digress; we're nowhere near doing this yet.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBKHK8ACgkQ2ugaI38ACPANNgEAg2K70CzsDPRF7MhBPRoSPtHm
ngLhrWQKqQ7+A74BTJ4BAKxDyUFnAD4ikYrGvo51Ez1FWcGXntQqyiPc/W+491l7
=8+LW
-END PGP SIGNATURE-

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michał Górny]

On Fri, 7 Sep 2012 12:46:41 -0300
Alexis Ballier  wrote:

> I actually do like the concept but I'm not sure we can reach consensus
> about '*DEPEND vs DEPENDENCIES'; a possibility to get people used to
> it could be to have two parallel EAPIs, like 6 and 6-dependencies,
> where the former will keep the old style and the latter use
> DEPENDENCIES.

With eclasses supporting both of them? That's more than crazy.

> After some time has passed, it could be decided to kill the less
> useful one, say in EAPI 8, and get only one 'latest' EAPI again. This
> decision doesn't need to be left only to the council, but since it
> affects everyone it could be a vote from all the dev community.

Why the dev community only? We have many active contributors who aren't
devs and who work hard with ebuilds. It's *their* time which will be
wasted on rewriting dependencies into new form, not yours.

> There is also the possibility that a consensus will never be reached
> and that the two styles will have to live forever, but after all, the
> EAPI concept is made for this.

I believe the correct concept is 'fork'. And that's what Exherbo did.

> Given this possibility, a debate 'I perfer *DEPEND' vs 'DEPENDENCIES
> are more flexible' doesn't make much sense now. What should be
> discussed is the concept itself.
> 
> For example, what is the HDEPEND equivalent for DEPENDENCIES ? exherbo
> documentation doesn't seem to mention an equivalent label.

But Ciaran has just said that this isn't about the labels! It's about
a philosophy in life.

Seriously saying, this isn't about equivalent types. We can choose any
labels we like. It's all about the form in which we will do it.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Alexis Ballier]

I actually do like the concept but I'm not sure we can reach consensus
about '*DEPEND vs DEPENDENCIES'; a possibility to get people used to it
could be to have two parallel EAPIs, like 6 and 6-dependencies, where
the former will keep the old style and the latter use DEPENDENCIES.

After some time has passed, it could be decided to kill the less useful
one, say in EAPI 8, and get only one 'latest' EAPI again. This decision
doesn't need to be left only to the council, but since it affects
everyone it could be a vote from all the dev community.

There is also the possibility that a consensus will never be reached
and that the two styles will have to live forever, but after all, the
EAPI concept is made for this.

Given this possibility, a debate 'I perfer *DEPEND' vs 'DEPENDENCIES are
more flexible' doesn't make much sense now. What should be discussed is
the concept itself.

For example, what is the HDEPEND equivalent for DEPENDENCIES ? exherbo
documentation doesn't seem to mention an equivalent label.

Alexis.

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Wulf C. Krueger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

(Just for the record, I don't care about the merits or demerits of
*DEPEND or DEPENDENCIES.)

> Ah, I forgot how the goals change *everything*. Because it's good
> to kill hundreds of people for the good reasons.

You might want to take a short break to consider if you're taking
things a bit too seriously or are at least phrasing them a little
strongly here.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlBKEgMACgkQnuVXRcSi+5rfbgCfRyC+mXV1NTDMt+n79q2kQtox
qjwAoMDIcoFcGdYJ9HM2gt9zSDoJp2pC
=RTIv
-END PGP SIGNATURE-

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michał Górny]

On Fri, 7 Sep 2012 16:07:54 +0100
Ciaran McCreesh  wrote:

> On Fri, 7 Sep 2012 17:02:57 +0200
> Michał Górny  wrote:
> > > The problem is that you're arguing against a proposal that doesn't
> > > exist except in your head. If you'd like to read and understand
> > > the proposal being made, which starts with understanding the bits
> > > marked clearly with stars, and then once you've understood it,
> > > rethink and present any issues you find with that proposal then
> > > we might have something to discuss.
> > 
> > Renaming and/or reordering something doesn't change its
> > implications. It's just 'main disadvantage' vs 'side disadvantage'.
> 
> Well no. You've been arguing against some mysterious proposal that
> doesn't exist that you think is about replacing lots of variables with
> one variable. That's not what DEPENDENCIES is, and now that you've got
> a proper write-up, you can try reading it, understanding it and then
> seeing if you have any objections to what's actually being proposed.

Ah, I forgot how the goals change *everything*. Because it's good to
kill hundreds of people for the good reasons.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

On Fri, 7 Sep 2012 17:02:57 +0200
Michał Górny  wrote:
> > The problem is that you're arguing against a proposal that doesn't
> > exist except in your head. If you'd like to read and understand the
> > proposal being made, which starts with understanding the bits marked
> > clearly with stars, and then once you've understood it, rethink and
> > present any issues you find with that proposal then we might have
> > something to discuss.
> 
> Renaming and/or reordering something doesn't change its implications.
> It's just 'main disadvantage' vs 'side disadvantage'.

Well no. You've been arguing against some mysterious proposal that
doesn't exist that you think is about replacing lots of variables with
one variable. That's not what DEPENDENCIES is, and now that you've got
a proper write-up, you can try reading it, understanding it and then
seeing if you have any objections to what's actually being proposed.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michał Górny]

On Fri, 7 Sep 2012 15:53:50 +0100
Ciaran McCreesh  wrote:

> On Fri, 7 Sep 2012 16:23:16 +0200
> Michał Górny  wrote:
> > On Fri, 7 Sep 2012 13:36:05 +0100
> > Ciaran McCreesh  wrote:
> > > > These are the rules for a machine. People don't actually read
> > > > dependencies sequentially. Provide a good algorithm which works
> > > > from any position.
> > > 
> > > Read backwards from the current position until you find a label.
> > > It's the same algorithm you use to find out what the current
> > > section is when you're reading an article.
> > 
> > No, it doesn't work that way.
> > 
> > See:
> > 
> >   foo? (
> > label:
> >   dev-foo/bar
> >   )
> >   dev-bar/foo <-
> > 
> > Reading backwards, I find 'label'.
> 
> ...skipping subblocks. Although the case you've given is unlikely to
> be used in practice, since experience shows that given this feature,
> developers use it in an easily understood manner.
> 
> > > > shall we repeat all the disadvantages which you love to forgot
> > > > to mention?
> > > 
> > > No, please stay out of this until you understand the original
> > > proposal, and in particular the parts marked with ***. So long as
> > > you don't understand what we're discussing, I'm afraid any
> > > contributions you make will simply be shouting and waving.
> > 
> > What have parts marked with '***' to do with the disadvantages we
> > have already proved and which you didn't even bother answering?
> 
> The problem is that you're arguing against a proposal that doesn't
> exist except in your head. If you'd like to read and understand the
> proposal being made, which starts with understanding the bits marked
> clearly with stars, and then once you've understood it, rethink and
> present any issues you find with that proposal then we might have
> something to discuss.

Renaming and/or reordering something doesn't change its implications.
It's just 'main disadvantage' vs 'side disadvantage'.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 07 Sep 2012 10:50:40 -0400
Ian Stakenvicius  wrote:
> On 07/09/12 07:45 AM, Ciaran McCreesh wrote:
> > [ Snip! ] Note also how the foo-related things, the bar-related
> > things etc cannot be grouped together by their fooness or barness,
> > but are rather grouped by their DEPENDness and RDEPENDness.
> > 
> > [ Snip! ]
> > 
> > So here's what DEPENDENCIES solves:
> > 
> > Firstly, it allows developers to group together foo-related
> > dependencies and bar-related dependencies by their fooness and
> > barness, not by their role. [ Snip! ] *** It does it by replacing
> > the concept of "a package has build *** dependencies, run
> > dependencies, etc" with "a package has *** dependencies, and each
> > dependency is applicable at one or more of *** build time, run tme,
> > etc".
> 
> And this is the specific point that I don't like about DEPENDENCIES
> versus *DEPEND.  As a developer, I personally find it much more
> straight-forward to fill in the deps needed for each role, rather than
> specifying the role(s) that each dep will play a part in.

Have you tried doing both? You may find you're just arguing from
familiarity, and that after having worked the other way for a few
packages, that the advantages become clearer.

The wide-spread use of hacks like COMMON_DEPEND are a pretty strong
indication that people *do* think in something closer to a
DEPENDENCIES-like fashion. In particular, I find it hard to believe
that you think "ok, so I've got a build dependency upon
>=cat/pkg-2.3[foo]" and then independently work out "ok, I've got a run
>dependency upon >=cat/pkg-2.3[foo]".

- -- 
Ciaran McCreesh
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlBKC6cACgkQ96zL6DUtXhG94gCgmXP0C+nAItSnCTIMoeJHzqzK
AyYAniXFZR5mJrBtuGI10dWt0nuJFhwc
=vZBn
-END PGP SIGNATURE-

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

On Fri, 7 Sep 2012 16:23:16 +0200
Michał Górny  wrote:
> On Fri, 7 Sep 2012 13:36:05 +0100
> Ciaran McCreesh  wrote:
> > > These are the rules for a machine. People don't actually read
> > > dependencies sequentially. Provide a good algorithm which works
> > > from any position.
> > 
> > Read backwards from the current position until you find a label.
> > It's the same algorithm you use to find out what the current
> > section is when you're reading an article.
> 
> No, it doesn't work that way.
> 
> See:
> 
>   foo? (
> label:
>   dev-foo/bar
>   )
>   dev-bar/foo <-
> 
> Reading backwards, I find 'label'.

...skipping subblocks. Although the case you've given is unlikely to
be used in practice, since experience shows that given this feature,
developers use it in an easily understood manner.

> > > shall we repeat all the disadvantages which you love to forgot to
> > > mention?
> > 
> > No, please stay out of this until you understand the original
> > proposal, and in particular the parts marked with ***. So long as
> > you don't understand what we're discussing, I'm afraid any
> > contributions you make will simply be shouting and waving.
> 
> What have parts marked with '***' to do with the disadvantages we have
> already proved and which you didn't even bother answering?

The problem is that you're arguing against a proposal that doesn't
exist except in your head. If you'd like to read and understand the
proposal being made, which starts with understanding the bits marked
clearly with stars, and then once you've understood it, rethink and
present any issues you find with that proposal then we might have
something to discuss.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/09/12 07:45 AM, Ciaran McCreesh wrote:
> [ Snip! ] Note also how the foo-related things, the bar-related
> things etc cannot be grouped together by their fooness or barness,
> but are rather grouped by their DEPENDness and RDEPENDness.
> 
> [ Snip! ]
> 
> So here's what DEPENDENCIES solves:
> 
> Firstly, it allows developers to group together foo-related
> dependencies and bar-related dependencies by their fooness and
> barness, not by their role. [ Snip! ] *** It does it by replacing
> the concept of "a package has build *** dependencies, run
> dependencies, etc" with "a package has *** dependencies, and each
> dependency is applicable at one or more of *** build time, run tme,
> etc".

And this is the specific point that I don't like about DEPENDENCIES
versus *DEPEND.  As a developer, I personally find it much more
straight-forward to fill in the deps needed for each role, rather than
specifying the role(s) that each dep will play a part in.

Although I realize that technically I could still do that (have the
dep list be role-centric rather than dep-centric), given that the
point of this change is (as stated above) to organize deps the other
way, I can't really get behind the idea.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBKCcAACgkQ2ugaI38ACPDARgD+Inqa+/o1kTqlfuf7gC6wa3Da
YAmj/F7Glno1QuzALboA/1l/XCbTr27XBGv7ULcvN0rdqqrBmarA8CgsySQiZRUB
=Xwaz
-END PGP SIGNATURE-

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michał Górny]

On Fri, 7 Sep 2012 13:36:05 +0100
Ciaran McCreesh  wrote:

> > These are the rules for a machine. People don't actually read
> > dependencies sequentially. Provide a good algorithm which works from
> > any position.
> 
> Read backwards from the current position until you find a label. It's
> the same algorithm you use to find out what the current section is
> when you're reading an article.

No, it doesn't work that way.

See:

  foo? (
label:
  dev-foo/bar
  )
  dev-bar/foo <-

Reading backwards, I find 'label'.
  
> > shall we repeat all the disadvantages which you love to forgot to
> > mention?
> 
> No, please stay out of this until you understand the original
> proposal, and in particular the parts marked with ***. So long as you
> don't understand what we're discussing, I'm afraid any contributions
> you make will simply be shouting and waving.

What have parts marked with '***' to do with the disadvantages we have
already proved and which you didn't even bother answering?

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

On Fri, 7 Sep 2012 14:29:41 +0200
Michał Górny  wrote:
> > Here's the important bit, which I shall prefix with some stars:
> > 
> > *** The point of DEPENDENCIES is not to replace n variables with one
> > *** variable.
> 
> Yes, it is.

You've clearly either completely missed the point of all of this,
despite it being pointed out to you, or are just trying to cause
trouble. Whilst you may be thinking of a DEPENDENCIES proposal that is
about replacing n variables with one variable (and I've never seen such
a proposal being made), what we're discussing here is not that. Kindly
stay out of this discussion until you understand what it is we're
discussing.

> These are the rules for a machine. People don't actually read
> dependencies sequentially. Provide a good algorithm which works from
> any position.

Read backwards from the current position until you find a label. It's
the same algorithm you use to find out what the current section is when
you're reading an article.

> The algorithm you presented above was technicality as well.

Agreed, but it was explicitly requested by Brian, so I provided it.

> So, now that your forked the thread

...as requested by Brian...

> shall we repeat all the disadvantages which you love to forgot to
> mention?

No, please stay out of this until you understand the original proposal,
and in particular the parts marked with ***. So long as you don't
understand what we're discussing, I'm afraid any contributions you make
will simply be shouting and waving.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michał Górny]

On Fri, 7 Sep 2012 12:45:59 +0100
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.
> 
> We observe that a typical package will have something like this:
> 
> DEPEND="
> cat/first
> cat/second
> cat/third
> cat/fourth
> foo? (
> foo/one
> >=foo/two-2.34[monkeys]
> )
> bar? (
>  bar/one
> )
> baz? (
>  baz/one
>  baz/two
> )
> fnord? (
>  fnord/one
> )"
> 
> RDEPEND="
> cat/second
> cat/third
> cat/fourth
> cat/fifth
> foo? (
> >=foo/two-2.34[monkeys]
> foo/three
> )
> bar? (
>  bar/one
>  bar/two
>  bar/three
>  bar/four
> )"

Now please express that using bash variable references instead of
the overly verbose expansions. Also, real examples are much more useful
than counting and monkeys. This is not mathematics.

> Note how many dependencies that we think of as being "the same" are
> listed in two places, and are not in any way "the same".
> 
> Note also how the foo-related things, the bar-related things etc
> cannot be grouped together by their fooness or barness, but are
> rather grouped by their DEPENDness and RDEPENDness.

What is fooness and barness? Because I got lost near the four
non-existent word.

> Right now we've just got three variables. In a not too distant EAPI,
> it will be considerably more than three. We also have duplication;
> with HDEPEND, this will sometimes become triplication.

Sometimes != always. Sometimes HDEPEND will actually simplify
the current state. By moving a few things from DEPEND to HDEPEND, we
may be actually able to remove COMMON_DEPEND. Sometimes.

> Here's the important bit, which I shall prefix with some stars:
> 
> *** The point of DEPENDENCIES is not to replace n variables with one
> *** variable.

Yes, it is.

> *** The point of DEPENDENCIES is not to provide syntactic sugar over a
> *** group of n variables.

Yes, it is.

> *** The point of DEPENDENCIES is to allow a package's dependencies,
> *** which can be very complicated, to be expressed accurately and
> *** simply, in a way friendly to how developers deal with dependencies
> *** in practice.

Didn't we already prove that the syntactic sugar DEPENDENCIES allows
can make the dependency specifications very unclear and not anywhere
close to simple?

> So here's what DEPENDENCIES solves:
> 
> Firstly, it allows developers to group together foo-related
> dependencies and bar-related dependencies by their fooness and
> barness, not by their role.
> 
> Secondly, it reduces error-prone duplication.

No, it doesn't. It just provides an alternate solution over how we do
that now. Does variable substitution ring a bell?

> Thirdly, it avoids some fairly obtuse names (BADEPEND? LDEPEND?) in
> favour of something a tad more readable.

That is a side effect. DEPENDENCIES doesn't disallow us from choosing
to use labels like 'd:', 'r:'. Similarly, bash variables don't anyhow
stand in the way of using more verbose names.

> Here's the other important bit, with more stars:
> 
> *** It does it by replacing the concept of "a package has build
> *** dependencies, run dependencies, etc" with "a package has
> *** dependencies, and each dependency is applicable at one or more of
> *** build time, run tme, etc".

Really?

I think it actually gives concept of 'a package has a few random groups
of dependencies, where each group is applicable at one or more of build
time, run time, etc and consists of one or more dependencies or groups
of dependencies, where each group is applicable at one or more of build
time, run time, etc (which may or may not be the same as parent group)
and consists of one or more dependencies or groups of dependencies,
where each group is applicable at one or more of build time, run time,
etc (which may or may not be the same as parent group) and consists of
one or more dependencies or groups of dependencies, where each group is
applicable at one or more of build time, run time, etc (which may or
may not be the same as parent group) and consists of one or more
dependencies or groups of dependencies, where each group is applicable
at one or more of build time, run time, etc (which may or may not be
the same as parent group) and consists of one or more dependencies or
groups of dependencies, where each group is applicable at one or more
of build time, run time, etc (which may or may not be the same as
parent group) and consists ...'

> We could just mark each dependency individually by when it's
> applicable. But that turns out to be quite verbose, since packages
> have fairly long lists of dependencies of the same k

[gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

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.

We observe that a typical package will have something like this:

DEPEND="
cat/first
cat/second
cat/third
cat/fourth
foo? (
foo/one
>=foo/two-2.34[monkeys]
)
bar? (
 bar/one
)
baz? (
 baz/one
 baz/two
)
fnord? (
 fnord/one
)"

RDEPEND="
cat/second
cat/third
cat/fourth
cat/fifth
foo? (
>=foo/two-2.34[monkeys]
foo/three
)
bar? (
 bar/one
 bar/two
 bar/three
 bar/four
)"

Note how many dependencies that we think of as being "the same" are
listed in two places, and are not in any way "the same".

Note also how the foo-related things, the bar-related things etc cannot
be grouped together by their fooness or barness, but are rather grouped
by their DEPENDness and RDEPENDness.

Right now we've just got three variables. In a not too distant EAPI, it
will be considerably more than three. We also have duplication; with
HDEPEND, this will sometimes become triplication.

Here's the important bit, which I shall prefix with some stars:

*** The point of DEPENDENCIES is not to replace n variables with one
*** variable.

*** The point of DEPENDENCIES is not to provide syntactic sugar over a
*** group of n variables.

*** The point of DEPENDENCIES is to allow a package's dependencies,
*** which can be very complicated, to be expressed accurately and
*** simply, in a way friendly to how developers deal with dependencies
*** in practice.

So here's what DEPENDENCIES solves:

Firstly, it allows developers to group together foo-related dependencies
and bar-related dependencies by their fooness and barness, not by their
role.

Secondly, it reduces error-prone duplication.

Thirdly, it avoids some fairly obtuse names (BADEPEND? LDEPEND?) in
favour of something a tad more readable.

Here's the other important bit, with more stars:

*** It does it by replacing the concept of "a package has build
*** dependencies, run dependencies, etc" with "a package has
*** dependencies, and each dependency is applicable at one or more of
*** build time, run tme, etc".

We could just mark each dependency individually by when it's
applicable. But that turns out to be quite verbose, since packages have
fairly long lists of dependencies of the same kind. So here's a much
more concise syntax:

DEPENDENCIES="
build:
cat/first
build+run:
cat/second
cat/third
cat/fourth
run:
cat/fifth

foo? (
build:
foo/one
build+run:
>=foo/two-2.34[monkeys]
run:
foo/three
)

bar? (
 build+run:
 bar/one
 run:
 bar/two
 bar/three
 bar/four
)

build:
baz? (
 baz/one
 baz/two
)

fnord? (
 fnord/one
)"

Here are the rules for working out which labels apply to a given spec:

We have a "labels stack" when parsing. Initially, the value "build+run"
is on the top. Whenever we encounter a block ("( )", "use? ( )" etc),
we duplicate the top value of the stack, and when we leave the block we
pop the value off. Whenever we encounter labels, we replace the top
value on the stack with those labels. Whenever we encounter a spec, its
associated labels are those on the top of the stack.

To avoid weirdness, so long as we're inside a || block, use of labels
is forbidden. Note that this is a reflection of the current ambiguity
as to what DEPEND="|| ( a b )" RDEPEND="|| ( a b )" means (can you
build against a, and run against b?), and if we're wanting to tidy that
up, that should be an independent proposal.

These rules are mostly for flexibility: if developers sometimes prefer
to group things by role rather than by fooness, then that's possible
too.

The rules for eclass merging need changing too, to add a ( ) around
values rather than merely appending. This is a technicality, and isn't
developer visible.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature