1 |
On Monday 02 November 2009 17:01:17 Jesús Guerrero wrote: |
2 |
> On Mon, 2 Nov 2009 16:12:49 +0200, Alan McKinnon <alan.mckinnon@×××××.com> |
3 |
> |
4 |
> wrote: |
5 |
> > On Monday 02 November 2009 15:58:57 Jesús Guerrero wrote: |
6 |
> >> On Mon, 2 Nov 2009 13:25:08 +0000, Neil Bothwick <neil@××××××××××.uk> |
7 |
> >> |
8 |
> >> wrote: |
9 |
> >> > On Mon, 02 Nov 2009 13:58:03 +0100, Jesús Guerrero wrote: |
10 |
> >> >> @preserved-rebuild never worked for me, maybe it's just that it |
11 |
> >> >> doesn't |
12 |
> >> >> like ~arch. I am just too lazy to work on how to fix a thing when |
13 |
> >> >> there's an alternative that always worked reliably, revdep-rebuild. |
14 |
> >> > |
15 |
> >> > If it didn't work on ~arch, how would it ever make it into arch? |
16 |
> >> |
17 |
> >> I am not the one to answer that, all I can say is that the few times |
18 |
> |
19 |
> I've |
20 |
> |
21 |
> >> tried it, it kept rebuilding the same packages again, and again, and |
22 |
> >> again |
23 |
> >> ad infinitum, as said, I didn't even bother to find what the problem |
24 |
> |
25 |
> was, |
26 |
> |
27 |
> >> because I have a working alternative. Sure it could be better, but that |
28 |
> >> hasn't been the case for me with @preserved-rebuild. |
29 |
> >> |
30 |
> >> I've seen people reporting the same problems in the forums, so I am |
31 |
> >> fairly |
32 |
> >> sure that's a common problem and not just exclusive to my |
33 |
> |
34 |
> installations. |
35 |
> |
36 |
> >> > The trouble with revdep-rebuild is that you have to break your system |
37 |
> >> |
38 |
> >> and |
39 |
> >> |
40 |
> >> > then fix it. Most of the time this is trivial, but updates like |
41 |
> >> |
42 |
> >> expat-2.0 |
43 |
> >> |
44 |
> >> > showed the usefulness of being able to recompile the packages before |
45 |
> >> |
46 |
> >> they |
47 |
> >> |
48 |
> >> > were broken. |
49 |
> >> |
50 |
> >> I can't understand that. You CAN'T recompile your packages against the |
51 |
> >> new |
52 |
> >> ABI's until the new ABI is in your system, and hence your system is |
53 |
> >> already |
54 |
> >> broken. There's no preemptive measure against this. Both methods fix |
55 |
> |
56 |
> the |
57 |
> |
58 |
> >> system *after* it's broken. |
59 |
> > |
60 |
> > Unless the old and the new ABI version are installed side by side. When |
61 |
> > @preserved-rebuild is run, it deletes the old libs only after everything |
62 |
> > left |
63 |
> > that used it is now linked against the new one. |
64 |
> |
65 |
> Thanks for the feedback. However there's one thing I can't understand: |
66 |
> whether the libraries are kept of removed is decided at the merge time, |
67 |
> isn't it? So, whatever breaks, breaks when using "emerge" to update the |
68 |
> offending library, the one that will break the ABI. So, how can using a |
69 |
> tool *after that* have any impact over what's broken? It can fix the |
70 |
> problem, but so can revdep-rebuild. |
71 |
> |
72 |
> I mean: if the old libs with the old abi's are kept, how it is relevant if |
73 |
> you are using @preserved-rebuild, revdep-rebuild or another method, or none |
74 |
> at all? Your programs will continue to work ok without needing to rebuild |
75 |
> anything, won't them? And after rebuilding the package it's irrelevant |
76 |
> *how* did you rebuild them... I must obviously be missing something here, |
77 |
> if you have the time please, direct me to an adequate source of information |
78 |
> or explain a bit, I am curious. |
79 |
|
80 |
Easy. Say you have app x which links to lib y: |
81 |
|
82 |
portage knows that x is linked to say y.1.0.0.so |
83 |
|
84 |
portage then upgrades y and puts y.so.1.0.1.so and the system helpfully thinks |
85 |
to itself "hang on a bit, I'm about to remove a library that Y is using. I'd |
86 |
better not do that!" and tells you so. (In the meantime you can merge anything |
87 |
you like that links to y.1.0.0.so, this does not affect @preserved-rebuild) |
88 |
|
89 |
You read the message, run @preserved-rebuild and x now links to the new y |
90 |
library. When everything in @preserved-rebuild has been rebuilt, portage knows |
91 |
that now nothing links to the old y library, and removes it. |
92 |
|
93 |
Do you see that the intent is to provide a bridging period where needed libs |
94 |
are not missing? And that @preserved-rebuild and revdep-rebuild do essentially |
95 |
the same function, except: |
96 |
|
97 |
1. Stuff does not break. OK, make that "stuff should not break" |
98 |
2. You don't have to hang around waiting for revdep-rebuild to take ages to |
99 |
run |
100 |
|
101 |
It can go south sometimes, the @preserved-rebuild magic is not always perfect |
102 |
and sometimes it gets confused. There's a file in /var somewhere that records |
103 |
this, so you can just delete it and run revdep-rebuild to get the old |
104 |
behaviour. Sometimes devs do stupid things with what they decide libs are |
105 |
called, and there's nothing portage can do about that except get itself |
106 |
confused (it's not a human and can't infer meaning). |
107 |
|
108 |
I've been using @preserved-rebuild for as long as it's been available (more |
109 |
than a year now?) with very very few hitches. I think you were just unlucky to |
110 |
hit a few stupid packages. |
111 |
|
112 |
|
113 |
> > There's only one case where this can't work - the developer changes the |
114 |
> > ABI |
115 |
> > and does not change the .so version number. That ain't gentoo's fault - |
116 |
> > shoot |
117 |
> > the developer. |
118 |
> |
119 |
> Of course, I can understand that. |
120 |
> |
121 |
> However and even if @preserved-rebuild has some reason to exist, it still |
122 |
> doesn't fix the weird behavior that it exhibited for me in the past. But to |
123 |
> tell the truth, I haven't tested lately. It just came to mi mind because of |
124 |
> the Dale's problem, which seems to be the same one. Please, understand that |
125 |
> I'm not complaining, merely describing my experience, I'd rather be filling |
126 |
> bugs than complain uselessly, it's just that -as I said- I really didn't |
127 |
> see a need to because the old way just works. |
128 |
|
129 |
yes, the old way does work. But it has this period in the middle where stuff |
130 |
is broken. |
131 |
|
132 |
Preserved-rebuild is an effort to do the same thing in a different order, to |
133 |
minimize breakage |
134 |
|
135 |
Of course, my entire understanding of this could be completely wrong. If so, |
136 |
someone will correct me :-) |
137 |
|
138 |
-- |
139 |
alan dot mckinnon at gmail dot com |