1 |
Alan McKinnon <alan.mckinnon@×××××.com> writes: |
2 |
|
3 |
> On Monday 12 July 2010 10:18:48 ZekeyG@×××××.com wrote: |
4 |
>> In linux.gentoo.user, you wrote: |
5 |
>> > On Saturday 10 July 2010 02:57:42 Nikos Chantziaras wrote: |
6 |
>> >> On 07/10/2010 04:16 AM, Valmor de Almeida wrote: |
7 |
>> >> > Hello, |
8 |
>> >> > |
9 |
>> >> > I just updated the portage tree and gcc was upgraded. I have set gcc |
10 |
>> >> > to the newer version |
11 |
>> >> > |
12 |
>> >> > -> gcc-config -l |
13 |
>> >> > |
14 |
>> >> > [1] i686-pc-linux-gnu-4.3.4 |
15 |
>> >> > [2] i686-pc-linux-gnu-4.4.3 * |
16 |
>> >> > |
17 |
>> >> > and I am trying to rebuild the whole system with |
18 |
>> >> > |
19 |
>> >> > emerge -e system |
20 |
>> >> > emerge -e world |
21 |
>> >> > |
22 |
>> >> > assuming this all goes without trouble (will take a while), should I |
23 |
>> >> > unmerge version 4.3.4? |
24 |
>> >> |
25 |
>> >> There's no reason to. Unless you don't need it anymore. |
26 |
|
27 |
And how do we know that? |
28 |
|
29 |
I, myself, wonder, as the previous version here is picked by depclean |
30 |
for removal. Can we trust depclean? I suppose if a package didn't |
31 |
compile and had no explicit dependency on the gcc version, that would be |
32 |
a good reason for a bug report and an ebuild change. |
33 |
|
34 |
>> http://www.gentoo.org/doc/en/gcc-upgrading.xml |
35 |
>> |
36 |
>> Suggests emerge -e system and emerge -e world in the "General Upgrade |
37 |
>> Instructions. |
38 |
> |
39 |
> It "suggests", it does not say it is mandatory with description of why. |
40 |
> |
41 |
> Periodically on this list this topic comes up and we re-hash again, for the |
42 |
> unmpteenth time, why the docs are misleading. That doc was apparently written |
43 |
> by someone who was looking for ways to minimize the amount of mail he gets. If |
44 |
> he says to rebuild system and world, then most of the questions he gets asked |
45 |
> just go away. Can't fault the dev for that.... |
46 |
|
47 |
Warning: following this handbook might lead to an infinite loop, when |
48 |
you sync after recompiling everything and you find a newer gcc version |
49 |
was marked stable, and you have to start again. |
50 |
|
51 |
If keeping both versions prevents the troubles fixed by recompiling |
52 |
everything, then it's just not worth it removing the old version (unless |
53 |
you own really fast machine). |
54 |
|
55 |
Suggesting "emerge -e" is anyway a possible solution for problems, just |
56 |
not the one to choose first. |
57 |
|
58 |
Can't we rely on revdep-rebuild, or write something to catch known |
59 |
upgrade issues? It sounds a |
60 |
|
61 |
while not okay |
62 |
run revdep-rebuild |
63 |
|
64 |
would be a better solution (but I don't know whether revdep-rebuild |
65 |
catches the issues --- probably not if there is an interface change but |
66 |
the library uses the same name as before...). |
67 |
|
68 |
> |
69 |
> This is all in the mail archives. Most of the whinging done by me actually |
70 |
> |
71 |
>> If you think the handbook is wrong or my interpretation of it wrong |
72 |
>> then *please* tell me. I would prefer *not* to go through this nightmare |
73 |
>> whenever GCC does a major version bump. |
74 |
> |
75 |
> You do not have to do what the handbook tells you, you just have to realise |
76 |
> what the handbook hopes to achieve. As hinted above, the intended result |
77 |
> appears to be least hassle for the gentoo devs and document writers with |
78 |
> maximal guarantee that your box will work afterwards regardless fo how long it |
79 |
> takes or number of cpu cycles burnt. It's not necessarily the most convenient |
80 |
> way. |
81 |
> |
82 |
> I have not had to rebuild world due to a compiler upgrade since sometime |
83 |
> around the late 3 series (there was a C++ ABI change). |
84 |
|
85 |
The one which involved emerging libstdc++-v3, and which rendered the |
86 |
whole system unusable due to a chicken and an egg? |
87 |
|
88 |
-- |
89 |
Nuno J. Silva |
90 |
gopher://sdf-eu.org/1/users/njsg |