[Bug 668243] Review Request: libqb - An IPC library for high performance servers.

[bugzilla at redhat.com]

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 at redhat.com> 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.