Re: sample nautilus SRPM does not build on RH 7.0

[Jens Finke <jens eknif de>]

On 21 May 2001, Gregory Leblanc wrote:
> > I had the same problem with a SuSE 7.0 installation. It's a 'bug' in glibc
> > somewhere, which results in a number of pointer arithmetic errors. We
> > shouldn't use this option if it breaks compilation on wide spread systems.
> > If a user recompiles a package, its mostly a tested official release,
> > which doesn't stop during compiling. The --enable-more-warnings option is
> > usefull if you actively develop software and are looking for possible
> > bugs.
>
> Hmm...  The Nautilus developers use RPMs actively to get a wider testing
> base, so we're not likely to see such a change in the CVS version of the
> spec file (and personally, I don't think such a change should go in).
> Perhaps we can put a recomendation into the CVS spec file, with a note
> about --enable-more-warnings.  Since it compiles if your glibc isn't
> broken, should we really not --enable-more-warnings?  Most of the people
> who compile it themselves should know how to read the spec file, at
> least a little bit.  If they can't do that, then they're probably using
> (or should be using) the binary packages.  What say you?

Well, this --enable-more-warnings thing is really useful if you hack e.g.
on nautilus. 'Cos if you create a possible bug (like pointer arithmetic)
the compilation stops with an error. But everyone should compile his
hacked version _before_ he checks his changes into CVS and fix these
issues. I think we can assume this behavior. This way, we have always a
compileable version of nautilus in CVS.

For user testing its important to get a widespread userbase, where every
user can easily compile the package himself. This should also include
'broken' systems like SuSE 7.0, RedHat 7.0 or others with the same bug.
And personally, I _never_ got any compile problems with any of the former
Eazel maintained packages according to the lack of --enable-more-warnings.
Instead I had to remove this flag everytime from the spec file, which is
just annoying. If we can avoid the regular remove-one-flag-in-spec-file
session, we should do this. It doesn't hurt anyone.

So my conclusion is: To reach the goal of providing simple to use spec
files, we should remove this flag from all former Eazel maintained
packages within the spec files.

    Jens

BTW: I've tested this on my SuSE 7.1 system, where the problem does not
exist.