The Gentoo GCC Upgrade Guide says in Chapter 2 (General Upgrade Instructions): >To be completely safe that your system is in a sane state, >you _must_ rebuild the toolchain and then world to make use >of the new compiler. > >Code Listing 2.2: Rebuilding system > ># emerge -eav system ># emerge -eav world In my case "system" is 404 and "world" is 1429 packages. On my netbook (Samsung N145, Intel(R) Atom(TM) CPU N450 @ 1.66GHz, 2GB DDR2 Ram, 20 GB of free disk space) "emerge -e system" took one day, and "emerge -e system" has already been running for 2 days with libreoffice (which alone took 15 hours, 47 minutes and 27 seconds last time) and 200 other packages yet to be emerged. The documentation does not explain what is meant with a "sane state" or what the purpose of all this rebuilding really is (and packages in system even twice). Why does sys-kernel/linux-docs (2 hours, 31 minutes and 47 seconds) has to be emerged again (it's only a bunch of man pages)? Why dev-java/sun-jdk and java-sdk-docs? Why dev-perl/*, dev-ruby/* and dev-java/*? Surely these packages are not affected by a gcc upgrade, or are they? Can the critical packages be determined in any way? Can I (safely!) speed up "emerge -e system" with USE="-docs" or other use flags? Is it safe to use distcc? At what point in the process? In which state must the rebuild process of the distccd system be? Can I skip "emerge -e system" when using distcc? In my opinion the upgrade guide should be more specific about the whys and hows of the rebuild, and it should give the user some options to speed up the whole rebuild process. On the other hand, maybe there needs to be some support tool to identify the critical packages, or portage/ebuilds could be made smarter and mark a package as critical for a gcc upgrade. If documentation alone cannot help please feel free to reassign this issue to other components.
You don't even 'need' to use the upgrade guide for minor gcc upgrades (4.x -> 4.y, let alone 4.x.y -> 4.x.z)
Its funny, as I was just explaining this particular situation to a few local Gentoo users after gcc-4.5.3 went stable. It appears to me that a brief little bit of guidance could benefit our users here. We could make a clear distinction between when the user 'needs' to rebuild and when then user 'might want to rebuild to take advantage of new features found in GCC in the case that it matters to them', i.e. we could write a few little bits that would explain when its a necessity versus when its a luxury to rebuild a all or some portion of the pkgs installed. It seems like this doc is a natural place to have such a treatment, since its linked in GCC's einfo. Anyone have any thoughts on modifying the documentation to make this more clear to users? Also, to the person filing this bug, the title is terribly misleading. Its the sort of title that will get a bug dismissed as invalid rather quickly as it is not actually descriptive of the content or purpose of your actual request, which if I am not mistaken, is to improve the documentation. Perhaps you were frustrated or something.
Re comment #1: As you maybe already guessed: the gcc upgrade is from 4.4.5 to 4.5.3-r1... and I am really confused now. The upgrade guide says: "If you install a new major version of GCC (such as 3.3.6 to 3.4.5)" ... So this is not a minor upgrade. Is the documentation wrong or misleading? What do I not understand?
Re comment #2 (concerning the bug title): Actually I was (and still am) not sure what the solution should be (see last paragraph of the bug description). So I only stated my problem. I specifically chose "enhancement" over "bug" because the upgrade procedure works but simply takes such a long time. If the system and world rebuild is actually needless (that is, my system was already in a "sane" state) then it is a bug in the documentation (see comment #3) and the documentation should be fixed. Anyway, the time will come when a rebuild will be necessary. What then? How can I (and all other gentoo users) speed up the rebuild. The alternatives I see are: 1. Enhance the documentation 2. Provide a tool 3. Enhance portage and ebuilds But I cannot propose or request a specific solution (mainly because I do not known what the exact purpose of the rebuild is). And no, the bug has nothing to do with taking advantage of new features found in gcc but only with needed rebuilds.
Changed the bug title (sorry to whoever wanted to do that before... I pushed the wrong button).
The documentation should suggest "emerge -av system" instead of -e system.
To verify what Mr. Ruppert stated above, I have the following data from one of my systems. Running 'emerge -vp system' yields 46 packages to be built while running 'emerge -vpe system' yields 504 packages. The '--emptytree' or '-e' behaves differently due to deep dependencies being considered. Now, I would like to note that while gcc and binutils are included in the 46 packages, glibc is not. I find this curious. Mainly since anytime I upgrade gcc I tend to then rebuild glibc, binutils and gcc again to insure the toolchain is consistent before I update @system which is followed by @selected if I feel so inclined. This habit seems to originate from working with converting a vanilla system over to a hardened profile. I am not certain if it matters, but it seems like good practice and has not caused me any issues other than taking some time.
I did forget to mention that I exclude binutils and gcc from the 'emerge -vp system' explicitly by invoking --exclude on both atoms.
I've (hopefully) started a discussion on gentoo-dev@g.o on the FUD surrounding GCC upgrades, since I am having a hard time finding correct information. I revamped the upgrading guide with what I believe is correct, but this is merely based on google'ing, personal experience and a quick chatter on IRC. http://dev.gentoo.org/~swift/docs/previews/gcc-upgrading.xml
Well, it looks like large rebuilds are usually not needed. The gcc upgrading guide has now been rewritten and updated to reflect what I hope is the correct way. At least, the gentoo-dev@g.o discussion seems to point out that it is. Document ought to be available within an hour or so on the site.
