1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Mike Frysinger wrote: |
5 |
> this is not a "implicit vs explicit" thread; if you want that discussion start |
6 |
> your own |
7 |
> |
8 |
> we've said the relationship of DEPEND atoms in ebuilds should be independent |
9 |
> of the DEPEND atoms found in eclasses as logically ebuilds should not care |
10 |
> what it takes for eclasses to work and vice versa ... for the most part, this |
11 |
> is true ... |
12 |
> |
13 |
> however, semi-recently, a change was made such that the implicit |
14 |
> RDEPEND=$DEPEND was dropped from ebuilds if an inherited class set RDEPEND in |
15 |
> any way ... that means if you have an ebuild at the moment that does: |
16 |
> DEPEND="foo" |
17 |
> and you dont inherit any eclasses, then you also get for free: |
18 |
> RDEPEND="foo" |
19 |
|
20 |
The change occurred sometime between portage-2.0.51 and portage-2.0.52, and the |
21 |
first stable version to have it was portage-2.0.53 (released in December of |
22 |
2005). People didn't really start to notice the difference until after |
23 |
portage-2.1 had been deployed on the master rsync mirror last June (it had been |
24 |
running portage-2.0.51.22-r3 up until then). |
25 |
|
26 |
> if you decide to inherit eclasses though, you had better do some research as |
27 |
> any eclass that does even RDEPEND="" will change that behavior ... or if you |
28 |
> are an eclass writer and you decided to add RDEPEND to your eclass, you had |
29 |
> better do a reverse check and make sure that any ebuild that inherits your |
30 |
> eclass (directly or indirectly) does not utilize implicit RDEPEND behavior as |
31 |
> you would have just broken it ... awesome ;) |
32 |
> |
33 |
> i posted a patch to fix this regression, but since it took so long before |
34 |
> anyone noticed, zmedico wants to see if anyone is opposed (i dont know why |
35 |
> they would be, but i cant think of everything) |
36 |
> |
37 |
> so to recap, the fix here changes it back to the historically documented |
38 |
> behavior that the implicit RDEPEND happens in ebuilds regardless of what |
39 |
> eclasses do |
40 |
> -mike |
41 |
|
42 |
If we do this then I want to make sure everybody is prepared for the |
43 |
consequences. Basically, it restricts implicit RDEPEND to the ebuild level, |
44 |
making it independent of whatever RDEPEND may or may not be defined in the |
45 |
inherited eclasses. That means that some ebuilds will get implicit RDEPEND |
46 |
that they don't get currently. Also, some ebuilds will loose some implicit |
47 |
RDEPEND that they current get from eclasses. |
48 |
|
49 |
I've attached the patch which reverts the behavior. If we do this, I think that |
50 |
we should do it in one big sweep, via a sys-apps/portage revbump and a |
51 |
simultaneous application of the patch on the master rsync mirror (see Brian |
52 |
Harring's email for more details). |
53 |
|
54 |
Zac |
55 |
|
56 |
-----BEGIN PGP SIGNATURE----- |
57 |
Version: GnuPG v1.4.5 (GNU/Linux) |
58 |
|
59 |
iD8DBQFFSwFI/ejvha5XGaMRArjaAKDi8B++F71vt3D2QkG5vyRhZ0yWvgCghBVA |
60 |
ZrVSROlN0E7X/xdkFbJ6NXo= |
61 |
=yRsF |
62 |
-----END PGP SIGNATURE----- |