| 1 |
Jeremy Huddleston <eradicator@g.o> posted |
| 2 |
E404CD4D-C436-43C8-AC25-F9EE90355851@g.o, excerpted below, on Thu, |
| 3 |
01 Jun 2006 01:48:16 -0700: |
| 4 |
|
| 5 |
> The old profiles are there because the files are in /etc which means |
| 6 |
> they're not removed when the version of gcc is unmerged. |
| 7 |
|
| 8 |
Duh. I was tired when I wrote about that and it shows, as the fact that |
| 9 |
CONFIG_PROTECT was involved never occurred to me! Lucky that |
| 10 |
factoid wasn't a cobra or I'd be in a morgue by now! Oh, well, still |
| 11 |
needed addressed, so it's for the best anyway. =8^) |
| 12 |
|
| 13 |
> This is fixed if you emerge the newest eselect-compiler, but you'll still |
| 14 |
> need to remove the old profile files manually. I should add something |
| 15 |
> to the ebuild to remove invalid profiles after the first install since |
| 16 |
> the CONFIG_PROJECT_MASK won't be valid until AFTER eselect-compiler is |
| 17 |
> installed. Thanks for pointing this out. |
| 18 |
|
| 19 |
Just merged -rc1-r4. I removed the 4.1.0 entry manually, and will do a |
| 20 |
bit more testing later today or early AM (right now another cobra might |
| 21 |
bite me! =8^). |
| 22 |
|
| 23 |
>> Of course, [the problem is] toolchain.eclass[,] unless you tweaked |
| 24 |
>> further after my emerges on May 26. |
| 25 |
>> |
| 26 |
> That depends on when on the 26th. I committed my changes on the 26th, |
| 27 |
> so I'm not sure what you have.[] I actually tested this by |
| 28 |
> using the 4.1.1_pre* gcc, then emerging 4.1.1. I saw both the i686 and |
| 29 |
> x86_64 compiler get updated. Perhaps you missed the fix by a few hours. |
| 30 |
> The toolchain.eclass commit was made a few hours after eselect-compiler |
| 31 |
> was updated. |
| 32 |
|
| 33 |
I probably missed it then. I'll be testing it later... |
| 34 |
|
| 35 |
>> but it's something that should be fixed |
| 36 |
>> before unmasking, I'm sure you'll agree. |
| 37 |
>> |
| 38 |
> Yes, I definitely agree here. The problem is with portage not unmerging |
| 39 |
> the files with gcc and QA wanting the base profile not to include the |
| 40 |
> override for eselect-compiler. This forced me to set |
| 41 |
> CONFIG_PROJECT_MASK via env.d for users who have eselect-compiler, but |
| 42 |
> that strands profiles for users who unmerge gcc before they get |
| 43 |
> eselect-compiler... thus I'm going to need to cleanup /etc/eselect/ |
| 44 |
> compiler on the first merge. |
| 45 |
|
| 46 |
Um... which came first, the chicken or the egg? <g> I guess that's about |
| 47 |
what you are stuck with. Certainly a challenge! |
| 48 |
|
| 49 |
>> Very cool idea, BTW |
| 50 |
>> |
| 51 |
> Great. Glad to see it working well for you. I've been using it as |
| 52 |
> well, and I'm just glad I got it to a usable state before work tore me |
| 53 |
> away from the project for so long. Hopefully I can get this finished |
| 54 |
> soon and start working on something similar for binutils. |
| 55 |
|
| 56 |
I'll be watching to see how it turns out. Actually having to manually |
| 57 |
write that first config based on your pattern, then see how it changed |
| 58 |
with each upgrade... Let's just say that being there at that stage of the |
| 59 |
process lends itself to learning opportunities one would almost certainly |
| 60 |
otherwise miss, if one jumped in after it's all automated. Sure, it's a |
| 61 |
bit of a hassle from time to time handling the stuff manually, but the |
| 62 |
drilling does reinforce the lesson. I'll be looking forward to the same |
| 63 |
sort of learning opportunities with binutils. I love that sort of |
| 64 |
hands-on learning, including the risk and challenge it entails, while at |
| 65 |
the same time exploring the leading edge before most people have any idea... |
| 66 |
|
| 67 |
-- |
| 68 |
Duncan - List replies preferred. No HTML msgs. |
| 69 |
"Every nonfree program has a lord, a master -- |
| 70 |
and if you use the program, he is your master." Richard Stallman |
| 71 |
|
| 72 |
-- |
| 73 |
gentoo-amd64@g.o mailing list |
Archives