I was working on a portage wrapper script for some of this. basically what i envision is a more powerful portage: 1.) allow for package specific cflags. an example is for avr-libc. -march isn't stripped out in the ebuild but should be. knowing this, i can choose to use a different set of cflags. another example is -ffast-math or -fnew-ra. these high-performance high-risk flags don't always work but can work well. i'd like to be able to use them _sometimes_. 2.) allow for easy gcc switching. 3.4.1 has issues on some ebuilds and 3.5.0 has issues on some. a package.gcc in /etc/portage might tell portage to switch to gcc3.3 for some ebuilds. 3.) you have already worked in package.use, which was a feature i wanted. thanks. 4.) allow for a cflags database for tweaker. basically the -ffast-math and -fnew-ra type flags are risky and no one wants to use them because they might not work. having some database of packages known not to work (or to work) with these risky flags would be nice. 5.) make a tool for package.keywords. IMO it is a bad idea to put things like nvidia-kernel ~x86 into the file because in the future you may not want to upgrade to them (eg 6106 vs 6111). however on updates you need to prevent downgrading... My proposal is to allow users to choose a version, then add that version to the package.keywords file, then update this file whenever a new -r[0-9] comes out. this way portage sees things like 2.0-r3 as being closer to 2.0-r1 instead of 1.9-r11 or 2.1-r1 Reproducible: Always Steps to Reproduce: na Actual Results: na Expected Results: na
Re coment #0 section 1) I use this file to get myself per package.cflags for my systems. The same logic could be extended easy enough to achieve most of the goals your after. It may be of some use to you. http://dev.gentoo.org/~solar/portage_misc/bashrc
#1, as solar shows, can be done already. A simpler solution will probably come about, but it probably won't be a cflags-specific config file. I don't think #2 is such a good idea. Portage shouldn't save the user from a buggy toolchain, nor should ebuilds contain that sort of information. #3 is already done. #4 is meaningless. A working combination of package/cflags is different for every arch/gcc version. There are way too many possibilities. #5 is already supported. Instead of "media-video/nvidia-kernel", use "~media-video/nvidia-kernel-1.0.6106". man 5 ebuild under depend atoms.
hmm, i will look into the bashrc script, i don't see where it changes cflags for each package as might be required during an upgrade. thanks for the info on the ~version. it shouldn't be too hard to implement a package.gcc either. while portage can't protect users from a bad toolchain, the people who are useing gcc3.4 and gcc3.5/4.0 are probably already aware of that. incorporating portage and gcc-config is the next logical step.
There is a technical flaw in that idea. portage would no longer be parallel aware in such situations. Picture this. tty1 emerge foo ; # foo calls gcc-config and sets compiler to 3.3.4 tty2 emerge bar ; # bar calls gcc-config and sets compiler to 3.4.2 What do you this the resulting object would look like?
If you want such optimizations, use solar's bashrc modifications. Portage will probably not support most of what you requested, but tools to manage existing package/profile files will probably come in the future. Portage developers will not support such arbitrary changes to the underlying system as all those functionalities support. They are for advanced users to figure out. If they cannot figure out how to manage it then they should not be attempting such finite control.
