On 09/10/2013 09:17 PM, Rich Freeman wrote: > On Tue, Sep 10, 2013 at 6:41 PM, Richard Yao <r...@gentoo.org> wrote: >> 1. The kernel expects -fno-stack-protector to be the default. What will >> the effect be on kernel configuration once -fstack-protector is the default? > > Nothing, since the kernel build system doesn't source make.conf. If > somebody creates an ebuild that actually installs a kernel then it > might be an issue, though it could be filtered if it is a problem.
My understanding is that this change would be made to GCC's spec files, which affects everything that uses GCC. >> >> 2. We should make sure that -fno-stack-protector is a supported CFLAG. >> This will make it easier to handle complaints from the vocal minority of >> our user base that want every last percentage point of performance. > > No reason that it would be any less supported than -fstack-protector > already is. Just making certain. >> >> 3. I would like to point out that we are talking about deviating from >> upstream behavior and everyone is okay with it. Anyone who thinks we >> should stick to upstream when it is not good for us should speak now or >> risk being asked "where were you when..." whenever they try to use >> upstream as an excuse to hold back progress. ;) > > I don't really see this as an issue - in general maintainers are > expected to accommodate reasonable CFLAGS. This doesn't mean that > arbitrary CFLAGS are "supported" so much as bugs should be taken > seriously if they're really bugs. If -fstack-protector causes serious > problems and this is inherent to the nature of the package/etc then > just filter it. If it causes problems because upstream isn't doing > things right, then this is no different than how things were 10 years > ago when we were stomping out amd64 issues left and right (not working > on amd64 wasn't a reason to mask a package for x86, but we didn't > accept "upstream doesn't care about amd64" as an excuse). > > Staying close to upstream is a good philosophy in general. I don't > think that means that we can't have reasonable CFLAGS. Otherwise we > wouldn't set CFLAGS at all and would just use whatever defaults the > upstream build system applies. We're a distro - doing integration > work is a value-add, not a sin. If we aren't doing integration, then > users might as well just do Linux-from-scratch. > > Rich > Past events have led me to think that we are sometimes too dependent on upstream for guidance. I have certainly deviated from upstream whenever it made sense and the results have been fairly positive. I am not saying that acting for the best interests of Gentoo is mutually exclusive with collaboration with upstream, but I am saying that the two sometimes conflict. This being one of them. I am taking this opportunity to point out that what is best for Gentoo should come first and that it is okay to make decisions on our own.
signature.asc
Description: OpenPGP digital signature
