"Martin Herrman" <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Wed, 10 Dec 2008 19:53:01 +0100:
> For the moment, I have chosen the most easiest way: > > sys-apps/portage > app-admin/eselect-news > app-admin/eselect > > added to package.keywords. Note that you may wish to use a complete package atom, including version, ~cat-egory/package-0.1.2 for instance, to include all -r revisions but no other versions, when you keyword, or =cat-egory/package-0.1*, to incluse 0.1.1, 0.1.2, etc, but not 0.2.0. That way portage won't try to automatically upgrade you to ~arch forever, only for that version. > That went smooth and everything seems to work > again (altough it adds the number of masked packages, which is a risk). > But.. I should now keep an eye on the development of glibc and portage > (etc.) packages so I can get back to the stable tree again? Can it take > months before gcc 4.3 and glibc 2.8 are stable? You'd have to ask toolchain or keep watch on the related bugs to see their comments, but in general, such toolchain packages can't stabilize until everything can either compile with them (ebuilds apply patches so it works), or in some cases, has other ebuild workarounds (in the worst cases, the ebuild may test for a version of gcc and die, telling the user it can't use that version, but that's for instance for cruft that won't compile with any gcc4 version at all, say). Then all those working ebuilds must themselves go stable, which is a minimum 30 day process in most cases. So indeed, it can takes months to stabilize such things. That said, I've had no problems with gcc-4.3.2 for some time now, tho part of that may be patches that are bugged but that I'm carrying locally -- they haven't been applied to the ebuilds yet, and where they are, those ebuilds may not be stable themselves yet, since I run all ~arch. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
