Re: -Werror

[John Marino <netbsd%marino.st@localhost>]

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

It's not about "respecting wishes", especially if doing so blocks a 
pkgsrc from working compilers less than 3 years old.


> 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.


> 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.


> 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?


> 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?


> 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.


> 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.


John