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 #12 from Fabio Massimo Di Nitto <fdinitto@xxxxxxxxxx> 2011-01-20 03:28:39 EST --- (In reply to comment #11) > (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. -O2 has changed in time as -O3 did. IME the only real safe option is to disable -O all together (yes I have been hitted several times by -O2 breakage in the past), and this is becoming a very academical discussion as it is clearly senseless to go -O0. If a piece of software is less performant with -O2 (see some crypto implementation for example), with such strong policy in place (the way you interpret it), will make Fedora a distribution I wouldnÂt want to see that software distributed. -g is used only to generate debugging information with gdb3 increasing the compatibility of the debugging info with gdb. It shouldnÂt have any effect on the final code being executed once the exec is stripped. hardly an issue here. > > => Consistent usage of these flags is vital to a distribution. > > Openly said, I wonder why I have to explain this. I am not asking you to repeat yourself. I am asking you to point me where in the Policy it states that flags *MUST* be treated the way you are suggesting. "Adding to and overriding or filtering parts of these flags is permitted if there's a good reason to do so; the rationale for doing so should be reviewed and documented in the specfile especially in the override and filter cases." What part of "is permitted" am I misinterpreting? > > > > > > > > > > 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. See, I have already fixed several upstreams to behave exactly this way (ship all autogenerated files etc), as I share this exact concerns (including the upstream that libqb used as source for this first upstream cut. libqb hasnÂt catch up yet but I know that will happen at somepoint). My point is that from a spec/package review process (since this is what we are doing here), none of the Fedora Policies in place do enforce one way or another. Taking those policy fight on a review is not the right forum or place. Trying to "exploit" a review to leverage a policy change is IMHO not the right way. Fabio -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review