Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=668243
--- Comment #11 from Ralf Corsepius rc040203@freenet.de 2011-01-20 01:37:29 EST --- (In reply to comment #10)
(In reply to comment #9)
(In reply to comment #8)
(In reply to comment #7)
2 MUSTFIXES:
- Package doesn't honor RPM_OPT_FLAGS.
The configure script plays nasty games with *FLAGS in a way they overwrite Fedora's *FLAGS.
Excerpt from my build.log: ... gcc -DHAVE_CONFIG_H -I. -I../include -I../include -I../include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -O3 -ggdb3 -Wall ....
Note: ... "RPM_OPT_FLAGS"... -O3 -ggdb3.
The later overwrite flags from RPM_OPT_FLAGS.
One way to fix this is to sed out the stuff which is responsible for this from configure.ac: e.g. by adding this before autogen.sh:
sed -i -e 's,OPT_CFLAGS="-O3",OPT_CFLAGS=,' \ -e 's,GDB_FLAGS="-ggdb3",GDB_FLAGS=,' configure.ac
I disagree with this approach as policy allow flags override.
http://fedoraproject.org/wiki/Packaging/Guidelines#Compiler_flags
You are mis-interpreting this.
On what base sorry?
Common sense and the fact I know about the intentions behind this paragraph.
None of the gcc security flags are overridden and so far you havenĀ“t given any technical reason on why optimization flags should not.
-OX and -g rsp. -gX are GCC flags which comprise many other GCC flags underneath.
What they exactly do changes over time and is machine/archtecture/OS dependent.
=> Consistent usage of these flags is vital to a distribution.
Openly said, I wonder why I have to explain this.
Should one of you be upstream, I'd seriously advise you to rework the configure.ac and to start making "make dist" working to ship proerly packaged tar-balls instead of .git snapshots.
make dist works just fine upstream, what problem are you experiencing exactly?
The tarball is improperly packaged - E.g. its lack all auto*generated files, which forces the Fedora packager to explictly pull in the autotools.
Many upstreams do not ship autogenerated files and pull in autotools at build time.
Yes, There are many people who are abusing the autotools, like due to lack of understanding.
If this is an issue please provide a pointer to the Fedora packaging guideline that enforces upstream to behave as Fedora requires and/or mass-file bugs after policy has been made clear.
This isn't an issue to Fedora - It's an issue to such package's upstreams and to those people who try to maintain such packages in Fedora.
Running the autotools during builds simply means exposing people to non-determinisms. In other words, everytime somebody uses a different version of the autotools than upstream, this person is likely to face issues from this.
Rest assured, these issues are not of a theoretical nature, they are real.
Fedora Policy has only one draft to address that issue and it is still under discussion on what the correct behavior should be in those cases. As long the draft is not approved as official Policy, it cannot be enforced.
Not much of a problem - *I* don't have much of a problem with upstream being so rude to expose their user base to avoidable risks nor do I have a problem with fedora maintainers shooting themself into their own foot.