Alan McKinnon <alan.mckin...@gmail.com> writes: > On Monday 12 July 2010 10:18:48 zek...@gmail.com wrote: >> In linux.gentoo.user, you wrote: >> > On Saturday 10 July 2010 02:57:42 Nikos Chantziaras wrote: >> >> On 07/10/2010 04:16 AM, Valmor de Almeida wrote: >> >> > Hello, >> >> > >> >> > I just updated the portage tree and gcc was upgraded. I have set gcc >> >> > to the newer version >> >> > >> >> > -> gcc-config -l >> >> > >> >> > [1] i686-pc-linux-gnu-4.3.4 >> >> > [2] i686-pc-linux-gnu-4.4.3 * >> >> > >> >> > and I am trying to rebuild the whole system with >> >> > >> >> > emerge -e system >> >> > emerge -e world >> >> > >> >> > assuming this all goes without trouble (will take a while), should I >> >> > unmerge version 4.3.4? >> >> >> >> There's no reason to. Unless you don't need it anymore.
And how do we know that? I, myself, wonder, as the previous version here is picked by depclean for removal. Can we trust depclean? I suppose if a package didn't compile and had no explicit dependency on the gcc version, that would be a good reason for a bug report and an ebuild change. >> http://www.gentoo.org/doc/en/gcc-upgrading.xml >> >> Suggests emerge -e system and emerge -e world in the "General Upgrade >> Instructions. > > It "suggests", it does not say it is mandatory with description of why. > > Periodically on this list this topic comes up and we re-hash again, for the > unmpteenth time, why the docs are misleading. That doc was apparently written > by someone who was looking for ways to minimize the amount of mail he gets. > If > he says to rebuild system and world, then most of the questions he gets asked > just go away. Can't fault the dev for that.... Warning: following this handbook might lead to an infinite loop, when you sync after recompiling everything and you find a newer gcc version was marked stable, and you have to start again. If keeping both versions prevents the troubles fixed by recompiling everything, then it's just not worth it removing the old version (unless you own really fast machine). Suggesting "emerge -e" is anyway a possible solution for problems, just not the one to choose first. Can't we rely on revdep-rebuild, or write something to catch known upgrade issues? It sounds a while not okay run revdep-rebuild would be a better solution (but I don't know whether revdep-rebuild catches the issues --- probably not if there is an interface change but the library uses the same name as before...). > > This is all in the mail archives. Most of the whinging done by me actually > >> If you think the handbook is wrong or my interpretation of it wrong >> then *please* tell me. I would prefer *not* to go through this nightmare >> whenever GCC does a major version bump. > > You do not have to do what the handbook tells you, you just have to realise > what the handbook hopes to achieve. As hinted above, the intended result > appears to be least hassle for the gentoo devs and document writers with > maximal guarantee that your box will work afterwards regardless fo how long > it > takes or number of cpu cycles burnt. It's not necessarily the most convenient > way. > > I have not had to rebuild world due to a compiler upgrade since sometime > around the late 3 series (there was a C++ ABI change). The one which involved emerging libstdc++-v3, and which rendered the whole system unusable due to a chicken and an egg? -- Nuno J. Silva gopher://sdf-eu.org/1/users/njsg
