1 |
On Wed, Sep 27, 2006 at 02:24:41AM -0400, Mike Frysinger wrote: |
2 |
> On Monday 25 September 2006 14:16, Brian Harring wrote: |
3 |
> > Bad soname handling is just *part* of what BINCOMPAT could do; it's |
4 |
> > not the sole reason for it's existance, as such it's not quite right |
5 |
> > dismissing it just because it addresses a rarity the NEEDED approach |
6 |
> > doesn't. :) |
7 |
> |
8 |
> i dismiss it as being a real advantage and/or argument for taking BINCOMPAT |
9 |
> over an automated NEEDED scan |
10 |
> |
11 |
> as i said, if you have changed ABI without an ABI bump, then the upstream |
12 |
> package maintainer is screwing everyone who uses the package, not just |
13 |
> Gentoo ... so perhaps we should be talking to them to get the situation |
14 |
> resolved for all consumers, not just Gentoo |
15 |
|
16 |
Happens however; afaik, we also weren't monkey patching ssl in the |
17 |
past to preserve the abi either so it still is valid (although rare if |
18 |
upstream is behaving) scenario. |
19 |
|
20 |
|
21 |
> > *IF* we actually had that in place it would enable detecting and |
22 |
> > rebuilding c++ code whenever gcc pulls its next c++ abi change with |
23 |
> > appropriate deps in place (iow, kill off the implicit system deps). |
24 |
> |
25 |
> scanelf already does this ... the only time you need to rebuild is when the |
26 |
> ABI breaks ... aka libstdc++.so.5 -> libstdc++.so.6 |
27 |
> |
28 |
> > If that were the case, why do we have libraries listed in DEPEND then? |
29 |
> |
30 |
> because i have a short memory |
31 |
> |
32 |
> > Bleh, this is getting back to exactly my point that it's unbounded |
33 |
> > resolution. To support this, every step of execution would require |
34 |
> > scanning for dangling nodes to punt; aside from invalidating -p's |
35 |
> > output it *still* is a collision-protect hit. |
36 |
> |
37 |
> when the package upgrade detects an ABI change you recalculate the packages |
38 |
> that need to be rebuilt ... |
39 |
|
40 |
Reiterating, this screws over any form of up front calculation; |
41 |
dialup users/per minute connections can't rely on emerge -f to |
42 |
actually fetch all involved sources, -p results ain't guranteed |
43 |
valid, parallelization must now lock at each threads merge on the off |
44 |
chance a recalc is forced. |
45 |
|
46 |
This is a rather huge step *backwards*; it actually puts us at a |
47 |
similar level to autopackages 'resolver'. The approach would have to |
48 |
solve it perfectly imo for it to even be realistically considered. |
49 |
|
50 |
For your proposal to fly, it must address this somehow imo which |
51 |
isn't possible from where I'm sitting. |
52 |
|
53 |
|
54 |
> dangling nodes get recorded in the new package and considering these old files |
55 |
> are not detrimental to the health of the system, you can do such a cleanup |
56 |
> once at the end of the emerge |
57 |
|
58 |
It's not orphaning files, but your scheme doesn't work for any form of |
59 |
interruption; failed builds, user intervention, etc, they all can |
60 |
leave the lib stuck in the new contents. |
61 |
|
62 |
Dealing with that possibility means the manager has to maintain on |
63 |
disk a list of the refcount of each dangling libs to decrement, |
64 |
unmerge has to modify said list, etc. |
65 |
|
66 |
Further nastyness in short. |
67 |
|
68 |
|
69 |
> > It also involves changing vdb nodes from "installed and usable" to |
70 |
> > "installed/usable" or "lingering" |
71 |
> |
72 |
> no ... the old versions get merged into the new one as their existence is |
73 |
> purely hidden |
74 |
|
75 |
How exactly are they going to be hidden? A new file? If so, |
76 |
backwards compatibility for vdb for transitioning in such a support |
77 |
has to be addressed. |
78 |
|
79 |
|
80 |
> > Tracking BINCOMPAT should *not* be that hard. |
81 |
> |
82 |
> it's one more thing to keep track of and considering all of the possibilities |
83 |
> i outlined, a single maintainer can easily lose his sanity ... or you force |
84 |
> wasted rebuilds on people when it's only needed in some circumstances |
85 |
|
86 |
How exactly is this forcing wasted rebuilds? You're stating that |
87 |
maintainers are going to bump it willy nilly. As I said, it is a key |
88 |
that would be bumped *as needed*, and would only affected pkgs that |
89 |
specified that node as a binding dep (specially marked atom). |
90 |
|
91 |
Seriously, maintainers ought to know *now* when they're forcing a |
92 |
revdep on folks systems, I'm not seeing the massive overhead from |
93 |
pushing that info into a var, nor am I seeing mass forced useless |
94 |
rebuilds. |
95 |
|
96 |
What I *am* seeing is one cluster fuck done to resolution and some |
97 |
nasty side affects you're glossing over. Invalidating -p's output |
98 |
opens up some nasty issues. |
99 |
|
100 |
To be fair, one claimed con could be that it is one more knob |
101 |
maintainers have to fool with, although counter is that they should |
102 |
already know about the issue (see dev quiz about "what should be done |
103 |
when bumping a lib" for an example). |
104 |
|
105 |
|
106 |
> > Hell, automate a tool to determine if it's a BINCOMPAT bump via NEEDED |
107 |
> > data (folks should be compiling the pkg anyways), point is it's mainly |
108 |
> > common sense for maintainenance of it. |
109 |
> |
110 |
> and when are you going to run that tool ? when you bump the package ? |
111 |
|
112 |
One would hope that when bumping a package, the dev actually attempts |
113 |
to *compile* the damn thing. Theres your opportunity to run a check, |
114 |
hell integrate it as a feature into portage that does the check for |
115 |
soname change. Gurantee that mod is far less intrusive, and far less |
116 |
error prone then what you're proposing. |
117 |
|
118 |
|
119 |
> so now |
120 |
> the maintainer has to test it on all the KEYWORDed arches with all the USE |
121 |
> combos, or de-KEYWORD it and make the arch maintainers test it ? |
122 |
|
123 |
Realistically, just the same as the NEEDED solution has holes, the |
124 |
maintaining dev can screw up and miss a BINCOMPAT bump. Difference is |
125 |
that they can do something for BINCOMPAT; hell, QA checks can be |
126 |
automated to catch missing BINCOMPAT bumps. |
127 |
|
128 |
Meanwhile, use flag affects: use deps reduce this heavily (toggle a |
129 |
flag off, graph is incomplete and the resolver 'fixes' it), so that's |
130 |
actually solvable *without* bincompat. |
131 |
|
132 |
KEYWORDed arches bit, bit unlikely that the underlying arch is |
133 |
actually going to screw with the soname, thus I'd want actual examples |
134 |
backing it up. |
135 |
|
136 |
Besides, again, for keywording, the dev *should* be compiling it, so |
137 |
there is a way to catch it :P. A revbump isn't going to break things |
138 |
unless the dev is introducing something intrusive, minor version bumps |
139 |
(1.1.0 to 1.1.1) shouldn't be again, introducing anything intrusive; |
140 |
regardless, dev should know the high level affects of their change |
141 |
|
142 |
Inducing a revdep-rebuild is definitely one of those high level |
143 |
changes they should be aware of *prior* to the bump. |
144 |
|
145 |
|
146 |
> or dig |
147 |
> through the source code line by line and hope to catch all such cases by |
148 |
> hand/eye ? |
149 |
|
150 |
Bit of FUD here, although I spose I'll just point out that if so's |
151 |
change as massively as you're implying above, the affects on -p are |
152 |
that much worse. |
153 |
|
154 |
|
155 |
> > Yes, if the solution can be automated without flinging poo into the |
156 |
> > code, I'm for it; that said I know what the implementation is going to |
157 |
> > have to look like, and it's *nasty*. |
158 |
> |
159 |
> i dont think either of our solutions are satisfactory for all presented cases; |
160 |
> a hybrid model would be needed |
161 |
|
162 |
bind the checks in as a QA measure, enabled via FEATURES=stricter, |
163 |
used to maintain a metadata var. |
164 |
|
165 |
Keep in mind I'm not claiming that implementing the binding deps |
166 |
modification is all that simple for portage; what I'm pushing here is |
167 |
a general solution that can be abused for more then just soname, |
168 |
*while* not cluster fucking the resolver execution to hell and |
169 |
preserving bounded resolution. |
170 |
|
171 |
Finally, anyone got a general list of revdep events for the tree? |
172 |
Literally, pkg x version y forced a rebuild. revdep is annoying, but |
173 |
stats would be useful to actually evaluate the seperate proposals; |
174 |
related, getting stats for how often the various updaters were |
175 |
required to be ran for a particular pkgs upgrade would be useful in |
176 |
evaluating that particular gap NEEDED has. |
177 |
|
178 |
~harring |