Re: -Werror

[Alistair Crooks <agc%pkgsrc.org@localhost>]

On Sat, Oct 13, 2012 at 05:40:16PM +0200, John Marino wrote:
> On 10/13/2012 17:09, Alistair Crooks wrote:
> >The removal of -Werror from packages is wrong - here's why:
> >
> >1.  The authors put it there in the first place.  They did this
> >consciously, for a reason - because they want their software to be
> >warning, as well as error free.  It would be good to respect their
> >wishes.  Now it may be that they don't have the platform or cpp defs
> >in place which cause warnings.  But I do know that they want to be
> >informed about this.
> 
> This statement makes a LOT of assumptions.
> 1.  That the authors made an informed decision when they picked it
> 2.  That leaving -Werror for releasing wasn't an oversight / mistake
> 3.  That the software is still maintained upstream

Not sure I get the drift of what you're trying to say.  On the one
hand, you're saying that people just put -Werror into their programs
because it's a cargo cult thing to do, and yet you have all these
warnings/errors to fix that they haven't seen and don't know how to
deal with, and it's way beyond the number of hours in the day, so you
have to switch off -Werror. 

You can't have it both ways; which is it?
 
> It's not about "respecting wishes", especially if doing so blocks a
> pkgsrc from working compilers less than 3 years old.

Can you re-state this one for me, please? I can't parse it.

> >2. Moving to new versions of gcc has had this effect in the past.
> >We'll see it in the future, too. We've never used a club like -Werror,
> >there's no need.
> 
> I think this statement is false.
> Grepping for BUILDLINK transforms in makefile alone results in 38
> packages *BEFORE* the recent commits.  Add 3 more for
> CONFIGURE_ARGS/ENV and several more disabled through patches.
> Clearly this club has been used, quite often.

If that's the case, why are you switching off -Werror now?  Why wasn't
it done in the past for those packages?

> >3.  We're not alone.  Debian/Ubuntu has a large user base, and new
> >gcc.  So fixes will be coming from Debian packages too.
> 
> 
> Debian has an extensive patch system, so they can easily patch it
> out. This statement also assumes that pkgsrc updates packages to the
> latest version regularly.  That is not true for quite a large
> percentage of packages.  I have both upgraded and imported a number
> of packages over the last 6 months and I can tell you that doing so
> is not trivial. Sure, there are those that you change the version
> number and you're finished, but more typically it ends up taking 4x
> the amount of time you thought it would.  That's a huge commitment
> for a stupid Werror fix if that's the only reason you're upgrading.
> Even the intermediate approach that I used for mit-krb5 to bring in
> the upstream patch takes a fair amount of effort.

We've always taken the approach that quality is better than quantity,
as I mentioned later on.  Why are we now moving to a de-facto "it
doesn't matter what it does as long as it packages ok" model?

> >4.  Authors will be upgrading packages to deal with new versions of
> >gcc too - they want their software to compile warning and error free
> >now as before.  So upgrading the package is usually a better long-term
> >sustainable way of doing this than staying down-level but masking
> >warnings which are already fixed.  Case in point - xymon.
> 
> Okay, I agree with this.
> Yes, having the newest version in pkgsrc is the best long-term
> approach.  How do you accomplish that when the majority of the
> packages are maintained by pkgsrc-users (which I equate as "nobody")
> and others only update packages that interest them?

The case in point is xymon, and the maintainer wasn't asked in advance
about anything.

% grep MAINTAINER /usr/pkgsrc/net/xymon/Makefile 
MAINTAINER=             spz%NetBSD.org@localhost
%

It's been fixed properly now (thanks, Petra!).

> >5.  Switching off -Werror affects the whole package.  A warning in one
> >place may be benign.  It may be malignant in another place.  This is
> >exacerbated by conditional compilation, different systems, untested
> >codepaths etc.
> 
> 
> Well, this is true.
> DragonFly build world allows for per-file cflags.  Does pkgsrc?
> Maybe that's a compromise.
> 
> 
> >6.  In life, ignoring warnings is the wrong thing to do.  It is the
> >same in packaging systems.  Case in point:  I ignored lint warnings
> >when modifying pkg_install way back.  Some tosh about LP64 problems,
> >but I knew that as NetBSD ran on LP64 just fine, that lint was playing
> >up.  Well, turns out I was wrong, the warning was good, and I had just
> >consigned all the alpha users (and there were a lot in those days, it
> >was the era of the NASA storage arrays) to life without a packaging
> >system.  I'm grateful to Ross Harvey for pointing out the error of my
> >ways.  But I also learned to heed warnings.
> 
> 
> We can swap anecdotes?

Somehow, I think you're missing the point.  If you can give me an
anecdote that shows how ignoring warnings is a good thing, that would
be cool.  Oh, and extra credit given for mentioning NASA in the same
sentence.

> >7. -Werror is such a big club, it's being turned off on all platforms.
> >This is wrong. Not all platforms are the same, in terms of user base,
> >ability to get hands dirty, or system basics. And most especially of
> >users on that platform.
> 
> 
> No user should expect to get his "hands dirty" just as pkgsrc
> committers should not be expected to fix actual bugs (beyond
> bringing in an approved upstream patch).  I don't see anything wrong
> treating all platforms the same.

Really? I've found the NetBSD user base out there to be one of the most
clueful around. It's why I joined the project in the first place.

> >8.  What's the point?  Yes, I could point to a number on a bulk build
> >log which says I now have n+700 packages a-packaging, but, long term,
> >that is meaningless.  We have never played the numbers game in pkgsrc,
> >because we believe that having strength in depth, working
> >cross-platform, and with good quality packages, is the right thing to
> >do.
> 
> 
> My response is the same as I said to Alek.  If this is truly a
> pkgsrc command decision, then highlight all circa 50 packages that
> disable -Werror, mark them broken for all platforms, and then people
> can fix them one by one.  It makes no sense to pick on 5 more after
> 50 are already in place.

That's not a response, though, that's avoiding the question. What exactly
is the point of all this? Is it just to boost the numbers of packages?

Regards,
Alistair