Jeremy Huddleston <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Thu, 01 Jun 2006 01:48:16 -0700:
> The old profiles are there because the files are in /etc which means > they're not removed when the version of gcc is unmerged. Duh. I was tired when I wrote about that and it shows, as the fact that CONFIG_PROTECT was involved never occurred to me! Lucky that factoid wasn't a cobra or I'd be in a morgue by now! Oh, well, still needed addressed, so it's for the best anyway. =8^) > This is fixed if you emerge the newest eselect-compiler, but you'll still > need to remove the old profile files manually. I should add something > to the ebuild to remove invalid profiles after the first install since > the CONFIG_PROJECT_MASK won't be valid until AFTER eselect-compiler is > installed. Thanks for pointing this out. Just merged -rc1-r4. I removed the 4.1.0 entry manually, and will do a bit more testing later today or early AM (right now another cobra might bite me! =8^). >> Of course, [the problem is] toolchain.eclass[,] unless you tweaked >> further after my emerges on May 26. >> > That depends on when on the 26th. I committed my changes on the 26th, > so I'm not sure what you have.[] I actually tested this by > using the 4.1.1_pre* gcc, then emerging 4.1.1. I saw both the i686 and > x86_64 compiler get updated. Perhaps you missed the fix by a few hours. > The toolchain.eclass commit was made a few hours after eselect-compiler > was updated. I probably missed it then. I'll be testing it later... >> but it's something that should be fixed >> before unmasking, I'm sure you'll agree. >> > Yes, I definitely agree here. The problem is with portage not unmerging > the files with gcc and QA wanting the base profile not to include the > override for eselect-compiler. This forced me to set > CONFIG_PROJECT_MASK via env.d for users who have eselect-compiler, but > that strands profiles for users who unmerge gcc before they get > eselect-compiler... thus I'm going to need to cleanup /etc/eselect/ > compiler on the first merge. Um... which came first, the chicken or the egg? <g> I guess that's about what you are stuck with. Certainly a challenge! >> Very cool idea, BTW >> > Great. Glad to see it working well for you. I've been using it as > well, and I'm just glad I got it to a usable state before work tore me > away from the project for so long. Hopefully I can get this finished > soon and start working on something similar for binutils. I'll be watching to see how it turns out. Actually having to manually write that first config based on your pattern, then see how it changed with each upgrade... Let's just say that being there at that stage of the process lends itself to learning opportunities one would almost certainly otherwise miss, if one jumped in after it's all automated. Sure, it's a bit of a hassle from time to time handling the stuff manually, but the drilling does reinforce the lesson. I'll be looking forward to the same sort of learning opportunities with binutils. I love that sort of hands-on learning, including the risk and challenge it entails, while at the same time exploring the leading edge before most people have any idea... -- 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 -- [email protected] mailing list
