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 <[email protected]> 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 [email protected] https://admin.fedoraproject.org/mailman/listinfo/package-review
