1 |
On Wednesday 27 September 2006 03:54, Brian Harring wrote: |
2 |
> On Wed, Sep 27, 2006 at 02:24:41AM -0400, Mike Frysinger wrote: |
3 |
> > as i said, if you have changed ABI without an ABI bump, then the upstream |
4 |
> > package maintainer is screwing everyone who uses the package, not just |
5 |
> > Gentoo ... so perhaps we should be talking to them to get the situation |
6 |
> > resolved for all consumers, not just Gentoo |
7 |
> |
8 |
> Happens however; afaik, we also weren't monkey patching ssl in the |
9 |
> past to preserve the abi either so it still is valid (although rare if |
10 |
> upstream is behaving) scenario. |
11 |
|
12 |
we've never monkey patched ssl so i dont really know what you're referring to |
13 |
|
14 |
> > > Bleh, this is getting back to exactly my point that it's unbounded |
15 |
> > > resolution. To support this, every step of execution would require |
16 |
> > > scanning for dangling nodes to punt; aside from invalidating -p's |
17 |
> > > output it *still* is a collision-protect hit. |
18 |
> > |
19 |
> > when the package upgrade detects an ABI change you recalculate the |
20 |
> > packages that need to be rebuilt ... |
21 |
> |
22 |
> Reiterating, this screws over any form of up front calculation; |
23 |
> dialup users/per minute connections can't rely on emerge -f to |
24 |
> actually fetch all involved sources, -p results ain't guranteed |
25 |
> valid, parallelization must now lock at each threads merge on the off |
26 |
> chance a recalc is forced. |
27 |
|
28 |
it does indeed prevent full up front calculation. we can always make the |
29 |
behavior configurable; revdep on the fly or allow people to break it up. the |
30 |
key being that their system will still continue to function as the ABI lib |
31 |
has been preserved automagically |
32 |
|
33 |
> > dangling nodes get recorded in the new package and considering these old |
34 |
> > files are not detrimental to the health of the system, you can do such a |
35 |
> > cleanup once at the end of the emerge |
36 |
> |
37 |
> It's not orphaning files, but your scheme doesn't work for any form of |
38 |
> interruption; failed builds, user intervention, etc, they all can |
39 |
> leave the lib stuck in the new contents. |
40 |
|
41 |
huh ? i outlined in a previous e-mail how by simply ordering the operations |
42 |
sanely, there is no race condition |
43 |
|
44 |
> Dealing with that possibility means the manager has to maintain on |
45 |
> disk a list of the refcount of each dangling libs to decrement, |
46 |
> unmerge has to modify said list, etc. |
47 |
|
48 |
which is already being done in the NEEDED file ... funny how unpainless it is |
49 |
to generate that file |
50 |
|
51 |
> > > It also involves changing vdb nodes from "installed and usable" to |
52 |
> > > "installed/usable" or "lingering" |
53 |
> > |
54 |
> > no ... the old versions get merged into the new one as their existence is |
55 |
> > purely hidden |
56 |
> |
57 |
> How exactly are they going to be hidden? A new file? If so, |
58 |
> backwards compatibility for vdb for transitioning in such a support |
59 |
> has to be addressed. |
60 |
|
61 |
purely hidden from the standpoint of any new package trying to use it ... |
62 |
since you're only installing the runtime ABI library, you cannot link against |
63 |
it or utilize it any way other than existing files |
64 |
|
65 |
> > > Tracking BINCOMPAT should *not* be that hard. |
66 |
> > |
67 |
> > it's one more thing to keep track of and considering all of the |
68 |
> > possibilities i outlined, a single maintainer can easily lose his sanity |
69 |
> > ... or you force wasted rebuilds on people when it's only needed in some |
70 |
> > circumstances |
71 |
> |
72 |
> How exactly is this forcing wasted rebuilds? You're stating that |
73 |
> maintainers are going to bump it willy nilly. As I said, it is a key |
74 |
> that would be bumped *as needed*, and would only affected pkgs that |
75 |
> specified that node as a binding dep (specially marked atom). |
76 |
|
77 |
no, i mean for example scenarios where a package provides more than one |
78 |
library (say libfoo and libbar) and only one of those changes ABI values (say |
79 |
libfoo.0 -> libfoo.1). if another package links against just libbar, you've |
80 |
got a pointless rebuild. |
81 |
|
82 |
> Seriously, maintainers ought to know *now* when they're forcing a |
83 |
> revdep on folks systems, I'm not seeing the massive overhead from |
84 |
> pushing that info into a var, nor am I seeing mass forced useless |
85 |
> rebuilds. |
86 |
|
87 |
there's a ton of things maintainers ought to know ... pretty soon our package |
88 |
maintainers are going to have to be gods if they want to write an ebuild as |
89 |
they're going to have to know every detail about the package inside and out |
90 |
|
91 |
> Realistically, just the same as the NEEDED solution has holes, the |
92 |
> maintaining dev can screw up and miss a BINCOMPAT bump. Difference is |
93 |
> that they can do something for BINCOMPAT; hell, QA checks can be |
94 |
> automated to catch missing BINCOMPAT bumps. |
95 |
|
96 |
what's the difference ? in my scenario they dont have to do anything because |
97 |
the bump would have been caught automatically ? |
98 |
|
99 |
> KEYWORDed arches bit, bit unlikely that the underlying arch is |
100 |
> actually going to screw with the soname, thus I'd want actual examples |
101 |
> backing it up. |
102 |
|
103 |
how about libc.so from glibc and libgcc.so from gcc ? or would you like other |
104 |
packages ? |
105 |
|
106 |
> Besides, again, for keywording, the dev *should* be compiling it, so |
107 |
> there is a way to catch it :P. A revbump isn't going to break things |
108 |
> unless the dev is introducing something intrusive, minor version bumps |
109 |
> (1.1.0 to 1.1.1) shouldn't be again, introducing anything intrusive; |
110 |
> regardless, dev should know the high level affects of their change |
111 |
|
112 |
uhh, there is no such requirement at this time for revbumping on different |
113 |
arches ... currently we say the maintainer tests for his arches and leaves |
114 |
all the others as ~arch |
115 |
|
116 |
> Inducing a revdep-rebuild is definitely one of those high level |
117 |
> changes they should be aware of *prior* to the bump. |
118 |
|
119 |
and yet we look at our history of so many packages being bumped with ABI |
120 |
changes and users having broken-as-shit systems ... i'm accounting for the |
121 |
worst; not hoping for the best |
122 |
|
123 |
> > or dig |
124 |
> > through the source code line by line and hope to catch all such cases by |
125 |
> > hand/eye ? |
126 |
> |
127 |
> Bit of FUD here, although I spose I'll just point out that if so's |
128 |
> change as massively as you're implying above, the affects on -p are |
129 |
> that much worse. |
130 |
|
131 |
awesome, mark something you disagree with as FUD, problem solved. my point is |
132 |
that you can never know completely for sure the behavior of a package without |
133 |
digging through the entire source code. |
134 |
|
135 |
> bind the checks in as a QA measure, enabled via FEATURES=stricter, |
136 |
> used to maintain a metadata var. |
137 |
|
138 |
a lot of things fail already with FEATURES=stricter ... too bad we dont have |
139 |
per-package env var support as then maintainers could just flag all their own |
140 |
packages as stricter without wanting to shoot themselves due to everyone |
141 |
else's package failures |
142 |
|
143 |
> Literally, pkg x version y forced a rebuild. revdep is annoying, but |
144 |
> stats would be useful to actually evaluate the seperate proposals; |
145 |
> related, getting stats for how often the various updaters were |
146 |
> required to be ran for a particular pkgs upgrade would be useful in |
147 |
> evaluating that particular gap NEEDED has. |
148 |
|
149 |
any openssl version bump where the numerical value changes ... only the letter |
150 |
updates preserve ABI compat (0.9.7[a-z] are compat) |
151 |
|
152 |
expat-1.x -> expat-2.x |
153 |
|
154 |
iirc, tcl-8.3.x -> tcl-8.4.x |
155 |
|
156 |
readline-4.x -> readline-5.x |
157 |
|
158 |
ncurses-4.x -> ncurses-5.x |
159 |
-mike |