| 1 |
this is not a "implicit vs explicit" thread; if you want that discussion start |
| 2 |
your own |
| 3 |
|
| 4 |
we've said the relationship of DEPEND atoms in ebuilds should be independent |
| 5 |
of the DEPEND atoms found in eclasses as logically ebuilds should not care |
| 6 |
what it takes for eclasses to work and vice versa ... for the most part, this |
| 7 |
is true ... |
| 8 |
|
| 9 |
however, semi-recently, a change was made such that the implicit |
| 10 |
RDEPEND=$DEPEND was dropped from ebuilds if an inherited class set RDEPEND in |
| 11 |
any way ... that means if you have an ebuild at the moment that does: |
| 12 |
DEPEND="foo" |
| 13 |
and you dont inherit any eclasses, then you also get for free: |
| 14 |
RDEPEND="foo" |
| 15 |
|
| 16 |
if you decide to inherit eclasses though, you had better do some research as |
| 17 |
any eclass that does even RDEPEND="" will change that behavior ... or if you |
| 18 |
are an eclass writer and you decided to add RDEPEND to your eclass, you had |
| 19 |
better do a reverse check and make sure that any ebuild that inherits your |
| 20 |
eclass (directly or indirectly) does not utilize implicit RDEPEND behavior as |
| 21 |
you would have just broken it ... awesome ;) |
| 22 |
|
| 23 |
i posted a patch to fix this regression, but since it took so long before |
| 24 |
anyone noticed, zmedico wants to see if anyone is opposed (i dont know why |
| 25 |
they would be, but i cant think of everything) |
| 26 |
|
| 27 |
so to recap, the fix here changes it back to the historically documented |
| 28 |
behavior that the implicit RDEPEND happens in ebuilds regardless of what |
| 29 |
eclasses do |
| 30 |
-mike |
Archives