Re: [gentoo-dev] Unified DEPENDENCIES concept

[Kent Fredric]

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

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 ferri...@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

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michał Górny]

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

 On Sat, Sep 15, 2012 at 11:06:01PM +1200, Kent Fredric wrote:
  On 14 September 2012 10:17, Brian Harring ferri...@gmail.com
  wrote:
   All you need is something in bash that can parse DEPENDENCIES and
   populate *DEPEND , and the underlying guts could be done in
   practically any language without requiring PM specific
   implementations.
  
   You've got it inverted; if any autopopulation is occuring,
   *DEPEND - DEPENDENCIES is the sane form.
  
   While it definitely *is* possible to render DEPENDENCIES down into
   depend/rdepend (after all, the PM has to do exactly this for
   resolution), that does /not/ mean doing it in bash is a good idea.
  
   I'd really not want to try that using labels; using use
   conditionals ('dep:run,build? ( targets )') is frankly a bit
   easier imo, but still; why do so unless one likes pain?  It
   doesn't actually gain us anything via missing the point of
   DEPENDENCIES.
  
   The point of unified DEPENDENCIES var (regardless of the form) is
   thus:
   1) ability to specify common deps once, w/out having to use
   intermediate vars/copy-pasting/etc.  Think COMMON_DEPEND, and this
   should make sense.
  
   2) To shift to a form where adding new dependency targets is easy-
   whether it be sdepend, fdepend, tdepend, or hdepend (or
   ONE-RING-DEPEND to rule them all).  This actually is rather
   important; for the average 95% case, devs won't actually have to
   pay much attention to those vars; but for those of us a bit
   further out (cross compilation, heavy parallelization, etc) those
   depend forms are becoming increasingly painful in their absense.
  
  
   Basically, having devs specify DEPENDENCIES in ebuilds, which
   then an eclass chunks out into DEPEND/RDEPEND misses the point of
   this; it's doable, it's just not particularly sane imo.
  
   The other way around, having *DEPEND automatically be collapsed
   into DEPENDENCIES, however is very sane- it makes
   transition/compatibilty for devs bloody simple, while structuring
   it so we can do further enhancements.
  
   ~harring
  
  
  
  Sure, but at least this makes it a viable proof-of-concept without
  needing all the different PM's to implement the new spec first, and
  due to not being EAPI bound when done this way, means you can just
  do it and have it work both now and in the future.
 
  And because of this experimental nature, you don't have to do
  *ALL* the parsing in bash, you could make the eclass use some
  external code to parse it and spit it out, and simply have the
  eclass depend on that external program regardless.
 
  I agree that long term, a Unified DEPENDENCIES implementation is the
  way forward, but if you want to convince people, having something
  which has been demonstrated and tested in a real world setting goes
  a long way.
 
 Honestly, QA would be well within their rights to kick anyone who did 
 this, *hard* in the shins.
 
 I understand your notion- specifically proof of concept, show the 
 data, etc; I just think you've still got inverted, too focused on 
 trying to do it in bash.
 
 To demonstrate the gain of this, we basically take the existing
 tree's deps, and re-render it into a unified DEPENDENCIES form.

But in order to do this, we first have to decide exactly what kind
of dependencies do we want to have. Then convert the tree to
a separate-variable form with new dependencies. Then we can compare
it with the DEPENDENCIES form and decide which one is better.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Kent Fredric]

On 11 September 2012 14:16, Brian Harring ferri...@gmail.com wrote:
 On Fri, Sep 07, 2012 at 04:14:17PM -0400, Ian Stakenvicius wrote:
 Is there anything in particular in the spec/proposal for DEPENDENCIES
 that would exclude the addition of individual build: app-cat/myatom
 run: app-cat/myatom deps by an eclass or eclasses?  I know the
 goal here is to make things atom-centric, but I can't see an
 implementation ever working of this that wouldn't permit the pile-on
 of additional entries of different (or even the same) roles on
 identical or near-identical atoms.

 They could be piled on; it would require each eclass to reset the
 label for safety reasons though; same goes for ebuilds frankly (or the
 PM would have to reset the context to build+run: each time through).

 Pardon if addressed elsewhere; this thread is a fucking mess...
 ~harring

Correct me if I'm wrong, but couldn't the entire proposition could be
implemented in an eclass, not needing the EAPI development cycle to be
tied up with it.

All you need is something in bash that can parse DEPENDENCIES and
populate *DEPEND , and the underlying guts could be done in
practically any language without requiring PM specific
implementations.

[[[

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 14, 2012 at 07:18:54AM +1200, Kent Fredric wrote:
 On 11 September 2012 14:16, Brian Harring ferri...@gmail.com wrote:
  On Fri, Sep 07, 2012 at 04:14:17PM -0400, Ian Stakenvicius wrote:
  Is there anything in particular in the spec/proposal for DEPENDENCIES
  that would exclude the addition of individual build: app-cat/myatom
  run: app-cat/myatom deps by an eclass or eclasses?  I know the
  goal here is to make things atom-centric, but I can't see an
  implementation ever working of this that wouldn't permit the pile-on
  of additional entries of different (or even the same) roles on
  identical or near-identical atoms.
 
  They could be piled on; it would require each eclass to reset the
  label for safety reasons though; same goes for ebuilds frankly (or the
  PM would have to reset the context to build+run: each time through).
 
  Pardon if addressed elsewhere; this thread is a fucking mess...
  ~harring
 
 Correct me if I'm wrong, but couldn't the entire proposition could be
 implemented in an eclass, not needing the EAPI development cycle to be
 tied up with it.
 
 All you need is something in bash that can parse DEPENDENCIES and
 populate *DEPEND , and the underlying guts could be done in
 practically any language without requiring PM specific
 implementations.

You've got it inverted; if any autopopulation is occuring, *DEPEND - 
DEPENDENCIES is the sane form.

While it definitely *is* possible to render DEPENDENCIES down into 
depend/rdepend (after all, the PM has to do exactly this for 
resolution), that does /not/ mean doing it in bash is a good idea.

I'd really not want to try that using labels; using use conditionals 
('dep:run,build? ( targets )') is frankly a bit easier imo, but still; 
why do so unless one likes pain?  It doesn't actually gain us 
anything via missing the point of DEPENDENCIES.

The point of unified DEPENDENCIES var (regardless of the form) is 
thus:
1) ability to specify common deps once, w/out having to use 
intermediate vars/copy-pasting/etc.  Think COMMON_DEPEND, and this 
should make sense.

2) To shift to a form where adding new dependency targets is easy- 
whether it be sdepend, fdepend, tdepend, or hdepend (or 
ONE-RING-DEPEND to rule them all).  This actually is rather important; 
for the average 95% case, devs won't actually have to pay much 
attention to those vars; but for those of us a bit further out (cross 
compilation, heavy parallelization, etc) those depend forms are 
becoming increasingly painful in their absense.


Basically, having devs specify DEPENDENCIES in ebuilds, which then an 
eclass chunks out into DEPEND/RDEPEND misses the point of this; it's 
doable, it's just not particularly sane imo.

The other way around, having *DEPEND automatically be collapsed into 
DEPENDENCIES, however is very sane- it makes transition/compatibilty 
for devs bloody simple, while structuring it so we can do further 
enhancements.

~harring

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

[Ciaran McCreesh]

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


signature.asc
Description: PGP signature

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michał Górny]

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


signature.asc
Description: PGP signature

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
 mich...@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.

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Matt Turner]

On Fri, Sep 7, 2012 at 4:45 AM, Ciaran McCreesh
ciaran.mccre...@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

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michał Górny]

On Fri, 7 Sep 2012 12:45:59 +0100
Ciaran McCreesh ciaran.mccre...@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.
 
 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 kind. So here's a
 much more concise syntax:
 
 

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Ciaran McCreesh]

On Fri, 7 Sep 2012 14:29:41 +0200
Michał Górny mgo...@gentoo.org 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 13:36:05 +0100
Ciaran McCreesh ciaran.mccre...@googlemail.com 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 16:23:16 +0200
Michał Górny mgo...@gentoo.org wrote:
 On Fri, 7 Sep 2012 13:36:05 +0100
 Ciaran McCreesh ciaran.mccre...@googlemail.com 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

[Ciaran McCreesh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 07 Sep 2012 10:50:40 -0400
Ian Stakenvicius a...@gentoo.org 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

[Michał Górny]

On Fri, 7 Sep 2012 15:53:50 +0100
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:

 On Fri, 7 Sep 2012 16:23:16 +0200
 Michał Górny mgo...@gentoo.org wrote:
  On Fri, 7 Sep 2012 13:36:05 +0100
  Ciaran McCreesh ciaran.mccre...@googlemail.com 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]

On Fri, 7 Sep 2012 17:02:57 +0200
Michał Górny mgo...@gentoo.org 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 16:07:54 +0100
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:

 On Fri, 7 Sep 2012 17:02:57 +0200
 Michał Górny mgo...@gentoo.org 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

[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

[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

[Michał Górny]

On Fri, 7 Sep 2012 12:46:41 -0300
Alexis Ballier aball...@gentoo.org 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

[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
 aball...@gentoo.org 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

[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

[Ciaran McCreesh]

On Fri, 7 Sep 2012 12:46:41 -0300
Alexis Ballier aball...@gentoo.org 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

[Michael Mol]

On Fri, Sep 7, 2012 at 12:11 PM, Ian Stakenvicius a...@gentoo.org 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
 aball...@gentoo.org 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:28:31 -0400
Michael Mol mike...@gmail.com 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

[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:
http://forums.gentoo.org/viewtopic-t-935812-start-0-postdays-0-postorder-asc-highlight-.html

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

[Michał Górny]

On Fri, 07 Sep 2012 18:12:08 +0200
Paweł Hajdan, Jr. phajdan...@gentoo.org 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

[Ciaran McCreesh]

On Fri, 07 Sep 2012 18:40:47 +0200
Paweł Hajdan, Jr. phajdan...@gentoo.org 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

[Zac Medico]

On 09/07/2012 09:10 AM, Ciaran McCreesh wrote:
 On Fri, 7 Sep 2012 12:46:41 -0300
 Alexis Ballier aball...@gentoo.org 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 09:53:46 -0700
Zac Medico zmed...@gentoo.org 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

[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 zmed...@gentoo.org
 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

[Zac Medico]

On 09/07/2012 09:58 AM, Ciaran McCreesh wrote:
 On Fri, 07 Sep 2012 09:53:46 -0700
 Zac Medico zmed...@gentoo.org 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

[Alexis Ballier]

On Fri, 7 Sep 2012 18:03:51 +0200
Michał Górny mgo...@gentoo.org wrote:

 On Fri, 7 Sep 2012 12:46:41 -0300
 Alexis Ballier aball...@gentoo.org 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 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 zmed...@gentoo.org
 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

[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
 zmed...@gentoo.org 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]

-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 
 zmed...@gentoo.org 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

[Michał Górny]

On Fri, 7 Sep 2012 14:40:25 -0300
Alexis Ballier aball...@gentoo.org wrote:

 On Fri, 7 Sep 2012 18:03:51 +0200
 Michał Górny mgo...@gentoo.org wrote:
 
  On Fri, 7 Sep 2012 12:46:41 -0300
  Alexis Ballier aball...@gentoo.org 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

[Michał Górny]

On Fri, 07 Sep 2012 13:58:00 -0400
Ian Stakenvicius a...@gentoo.org 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
  zmed...@gentoo.org 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

[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 
 zmed...@gentoo.org 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

[Ciaran McCreesh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 07 Sep 2012 11:18:28 -0700
Zac Medico zmed...@gentoo.org 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

[Ciaran McCreesh]

On Fri, 7 Sep 2012 20:23:23 +0200
Michał Górny mgo...@gentoo.org 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

[Michał Górny]

On Fri, 7 Sep 2012 19:31:16 +0100
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:

 On Fri, 7 Sep 2012 20:23:23 +0200
 Michał Górny mgo...@gentoo.org 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:46:48 +0200
Michał Górny mgo...@gentoo.org 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:52:05 +0100
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:

 On Fri, 7 Sep 2012 20:46:48 +0200
 Michał Górny mgo...@gentoo.org 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 21:11:22 +0200
Michał Górny mgo...@gentoo.org wrote:
 On Fri, 7 Sep 2012 19:52:05 +0100
 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
  On Fri, 7 Sep 2012 20:46:48 +0200
  Michał Górny mgo...@gentoo.org 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 20:13:19 +0100
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:

 On Fri, 7 Sep 2012 21:11:22 +0200
 Michał Górny mgo...@gentoo.org wrote:
  On Fri, 7 Sep 2012 19:52:05 +0100
  Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
   On Fri, 7 Sep 2012 20:46:48 +0200
   Michał Górny mgo...@gentoo.org 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:21:42 +0200
Michał Górny mgo...@gentoo.org 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

[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
 ciaran.mccre...@googlemail.com wrote:
 
 On Fri, 7 Sep 2012 20:23:23 +0200 Michał Górny
 mgo...@gentoo.org 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

[Alexis Ballier]

On Fri, 7 Sep 2012 20:21:03 +0200
Michał Górny mgo...@gentoo.org wrote:

 On Fri, 7 Sep 2012 14:40:25 -0300
 Alexis Ballier aball...@gentoo.org wrote:
 
  On Fri, 7 Sep 2012 18:03:51 +0200
  Michał Górny mgo...@gentoo.org wrote:
  
   On Fri, 7 Sep 2012 12:46:41 -0300
   Alexis Ballier aball...@gentoo.org 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

[Michał Górny]

On Fri, 7 Sep 2012 20:25:58 +0100
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:

 On Fri, 7 Sep 2012 21:21:42 +0200
 Michał Górny mgo...@gentoo.org 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

[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 mgo...@gentoo.org
 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 16:59:48 -0300
Alexis Ballier aball...@gentoo.org wrote:

 On Fri, 7 Sep 2012 20:21:03 +0200
 Michał Górny mgo...@gentoo.org wrote:
 
  On Fri, 7 Sep 2012 14:40:25 -0300
  Alexis Ballier aball...@gentoo.org wrote:
  
   On Fri, 7 Sep 2012 18:03:51 +0200
   Michał Górny mgo...@gentoo.org wrote:
   
On Fri, 7 Sep 2012 12:46:41 -0300
Alexis Ballier aball...@gentoo.org 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 04:10 PM, Michał Górny wrote:
 On Fri, 7 Sep 2012 16:59:48 -0300 Alexis Ballier
 aball...@gentoo.org wrote:
 
 On Fri, 7 Sep 2012 20:21:03 +0200 Michał Górny
 mgo...@gentoo.org wrote:
 
 On Fri, 7 Sep 2012 14:40:25 -0300 Alexis Ballier
 aball...@gentoo.org wrote:
 
 On Fri, 7 Sep 2012 18:03:51 +0200 Michał Górny
 mgo...@gentoo.org wrote:
 
 On Fri, 7 Sep 2012 12:46:41 -0300 Alexis Ballier
 aball...@gentoo.org 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

[Ciaran McCreesh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 07 Sep 2012 16:08:53 -0400
Ian Stakenvicius a...@gentoo.org 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

[Ciaran McCreesh]

On Fri, 7 Sep 2012 22:07:30 +0200
Michał Górny mgo...@gentoo.org wrote:
 On Fri, 7 Sep 2012 20:25:58 +0100
 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
  On Fri, 7 Sep 2012 21:21:42 +0200
  Michał Górny mgo...@gentoo.org 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

[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
 a...@gentoo.org 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]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 07 Sep 2012 16:28:40 -0400
Ian Stakenvicius a...@gentoo.org 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

[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

[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?