1 |
On Fri, Nov 03, 2006 at 02:29:45AM -0500, Mike Frysinger wrote: |
2 |
> this is not a "implicit vs explicit" thread; if you want that discussion start |
3 |
> your own |
4 |
|
5 |
That discussion (dropping it to explicit, as has been discussed often |
6 |
enough) should be started off again since fixing it isn't exactly a |
7 |
matter of applying a patch and ignoring it.... so... |
8 |
|
9 |
swegener? Feel free to chime in, you were one of the main folks |
10 |
after killing implicit from what I recall. |
11 |
|
12 |
Meanwhile... |
13 |
|
14 |
> we've said the relationship of DEPEND atoms in ebuilds should be independent |
15 |
> of the DEPEND atoms found in eclasses as logically ebuilds should not care |
16 |
> what it takes for eclasses to work and vice versa ... for the most part, this |
17 |
> is true ... |
18 |
> |
19 |
> however, semi-recently, a change was made such that the implicit |
20 |
> RDEPEND=$DEPEND was dropped from ebuilds if an inherited class set RDEPEND in |
21 |
> any way ... that means if you have an ebuild at the moment that does: |
22 |
> DEPEND="foo" |
23 |
> and you dont inherit any eclasses, then you also get for free: |
24 |
> RDEPEND="foo" |
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 |
|
41 |
Mildly screwed on this one from a cache standpoint; |
42 |
|
43 |
1) the change went out unversioned, meaning that while it was |
44 |
spreading, folks were getting a mix of it. Likely their are still |
45 |
cache entries distributed with gentoo-x86 that are still old style |
46 |
deps. |
47 |
|
48 |
Nice. |
49 |
|
50 |
2) Same issue via reverting it; it's an unversioned change, so portage |
51 |
will *not* pick up on it and fix it. Additionally, cause I was being |
52 |
anal about making --metadata as fast as possible, portage will *not* |
53 |
pick up the change since mtimes won't differ, thus will not write the |
54 |
new entry into the localized cache (cache.util.py, note the |
55 |
is_eclass_data_valid check controlling write_it boolean). |
56 |
|
57 |
#1 was stupid, #2 pretty royally gets us up the backside. |
58 |
|
59 |
|
60 |
So... my suggestion. Decide what you're going to do long term now, no |
61 |
more (bluntly) fucking around with this. |
62 |
|
63 |
|
64 |
Got a few courses of action from where I'm sitting- |
65 |
|
66 |
1) EAPI bump for the restored behaviour. This sucks since it forces |
67 |
the entire tree to be bumped to force falling back to older behaviour |
68 |
(this is why changes like this are supposed to be EAPI bumped in the |
69 |
first place btw). |
70 |
|
71 |
2) (several steps) |
72 |
2.a) Revbump all afflicted portage versions with a patch |
73 |
restoring original behaviour, leaving keywords the same (meaning |
74 |
2.1-r3 goes in with stable keywords); pull all portage versions that |
75 |
have the broken behaviour (>=2.1 basically). |
76 |
|
77 |
2.b) Force mtime touches of _all_ eclasses to force both rsync |
78 |
transfer within the mirror tier (can do this other ways), but more |
79 |
importantly, to force the transfer of all eclass consumers to the |
80 |
localized cache on folks machines. This at least gets them the old |
81 |
style deps in their cache. It will *not* fix the rdeps for overlay |
82 |
ebuilds that are afflicted, and does not fix it if the user triggers |
83 |
regeneration locally. |
84 |
|
85 |
3) ignore it, and laugh like nero till everyone has upgraded to a |
86 |
fixed version of portage and enough churn in the tree has occured to |
87 |
have forced the corrected cache entries locally. |
88 |
|
89 |
|
90 |
#1 blows since either it requires changing EAPI in every ebuild ( |
91 |
easier, base/profile.bashrc, although I never intended profile bashrc |
92 |
to influence ebuild metadata), or auditing the rdeps and fixing them, |
93 |
bumping when after older behaviour. Additionally, requires leaving a |
94 |
portage version behind at the older EAPI for upgrading. |
95 |
|
96 |
#2 is fairly brutal initially, but should clear out the corruption |
97 |
pretty quickly for majority of users; for overlay users and devs |
98 |
however, it relies on folks upgrading to a fixed portage fairly |
99 |
quickly so that rdeps are proper. Doubly so for devs, since their |
100 |
portage installation is the first line of dependency verification |
101 |
(folks running automated repoman/pcheck dependency scans being second |
102 |
line). |
103 |
|
104 |
One upshot though, this method will push the proper deps into the |
105 |
localized cache for stage* users. |
106 |
|
107 |
Downside is that it triggers a pretty heavy hit on rsync mirrors, |
108 |
although the eclass touching can be stretched out over a few days to |
109 |
incrementally push out the updated cache. |
110 |
|
111 |
#3 means that broken rdeps linger for the next few months till folks |
112 |
have upgraded, and the mess has gradually cleaned itself out. Will |
113 |
linger for a long while in older ebuilds, although a forced cache |
114 |
regen fixes it for folks who either wipe their localized cache, or |
115 |
somehow trigger a regen. |
116 |
|
117 |
So... I'd go with #2. |
118 |
|
119 |
Pardon the essay, but getting the effects of it fixed isn't trivial, |
120 |
and the long term lingering effects aren't either imo. |
121 |
|
122 |
So... thoughts? |
123 |
|
124 |
~harring |