We already had a bug about a 'official' cflags guide like 3 years ago and I think it's about time to re-open effort on this topic. I'm talking about adding more detailed information within the handbook about things not to do within gentoo. As the handbook provides only very little cover on this, people crowd together on gentoo-wiki.com/forums.gentoo.org/#gentoo and provide bogus information regarding ~arch and cflags. I use to be in #gentoo and at least 2/3 of the question arising are based on people running completly in ~arch or having bogus cflags. This IS a problem; not only to the community with it's little resources on providing useable solutions (80% of the patches in the tree are done by like 20% of the people involved) but also for the developers and the distribution itself. Gentoo - as a brand - should make a clear point about how it organizes itself, that people are neither supposed not supported in ~arch and that users are not ment to -eD world because they found out about -fomgfast. I'm not talking about locking people out of the development process (aka hiding ~arch from them) or redefining Gentoo. The current noise ratio in the community, produced by the community is - as far as I see - very high. Gentoo, imho, is currently the 'freeist' linux distribution, talking about 'free' not as in 'beer' but as in 'freedom'. I can see the code, I can download the code and I can compile the code. This is neither about speed/performance but about trust and I'd love to see people trust Gentoo. So after this preamble, some concrete proposals: * It's currently very hard for an average, especially new user to inform himself about the current development status. That is, there should be a central place on gentoo.org for certain hot topics like important packages going to stable arch. * ACCEPT_KEYWORDS="~arch" should be possible but not be considered good behaviour and treated as such. A single message in 'emerge' telling people about keywording only specific packages can do the job. * There is LOTS of noise about the CFLAGS. People give each other tips on setting stuff like -ffast-math, not realizing ebuilds do lots and lots of cflags filtering. There should be 'official' information, more specific than they currently are, on the cflags. There had been a gwn topic about that once, that needs to be within the handbook. Also the ebuild cflags-strip function should ewarn about cflags being stripped so users get the point. my two cents.
*** This bug has been marked as a duplicate of 68282 ***
'We already had a bug about a 'official' cflags guide like 3 years ago' - i talked about 68282. duping a 'let's re-open this topic' to a bug that got de-facto closed years ago *sigh*
