If a gcc prefernce varible could be added to /etc/make,conf. It could be used to specify behavior of gcc-config. EX:1 highest >4.1.1 always over any versions of 3.4.6 2 current > I always want my current version, I'll change when I want to) 3 hardened, hardenednopie, hardenednopiessp, hardenednossp. Actually it could be a 2 part variable GCC_PREFERNCE="higest-hardened" which in my case would be plain gcc-4.1.1 since there is no hardened options. If it was "hardened-highest" it would mean highest gcc with a hardened profile. The order of the flags or just a single flag such as "hardened" could indicate over all prefernce. Right now portage has a sneaky way of of OCCASSIONLY updating a lower sloted version of gcc. I have never been able to duplicate it and it could a combination of portage sees my guard is down and gcc-config is in a last emerged is current mode. Any way a GCC_PREFERNCE would take some of the heat off you as to,what is the users prefernce ? In a script I maintain I chose to allways select the highest version of gcc. That way those who care know whats going to happen when gcc is updated.
(In reply to comment #0) > Right now portage has a sneaky way of of OCCASSIONLY updating a lower sloted > version of gcc. I have never been able to duplicate it and it could a > combination of portage sees my guard is down and gcc-config is in a last > emerged is current mode. See Bug 130772. Otherwise, I don't understand this suggestion. Why do you want to duplicate gcc-config/eselect-compiler functionality in portage?
I'm not sure what you are even asking for here, but I agree with jakub, I think you are talking about bug #130772. If gcc-config is randomly changing versions on anything but an upgrade, you found a bug. I don't see the point in adding what you are requesting here. It seems extremely complicated to me.
*** Bug 134858 has been marked as a duplicate of this bug. ***
I don't see any point to what you are asking for. If anyone on toolchain disagrees with me, please hit me with the cluebat and tell me how this would be beneficial :)
The thought behind this was that at times gcc install will select what ever was last installed. If you are at gcc-4.1.1, selected, and theres a gcc-3.4.6-r1 update then on occassion the the gcc-3.4.6 will end up the selected gcc. Right now that isnt whats happening. Ive installed 3.4.5, 3.4.6 and have 4.1.1. gcc-4.1.1 is selected and didnt change when I reinstalled 3.4.5 or 3.4.6 . But it has happened and happened to a guy who posted to the emwrap.sh thread last week. Now I may have goten carried away with all the possibilities but if it was just a simple "current" or "highest" toggel then users would know what to expect after a gcc update. If a gcc update / upgrade behaviuor is going to remain consistant as it is now "leave at current gcc" then no this isnt needed.
