tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: -Werror

On 10/13/2012 18:13, Alistair Crooks wrote:
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.

I never said that I didn't know how to deal with them. The new warnings that are causing Werror to trip at develop-time advice, not anywhere close to being real errors. The problem is that they could be numerous. So the choice is to patch several non-problems (because the compiler will optimize correctly) or turn off Werror.

Don't forget that others disagree that Werror should be present in release software.

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.

I think working on new clang and gcc4.6 is more important than the concept of "respecting a wish" that might have been made 10 years prior.

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?

That question makes no sense.
There are say 50 packages that switch off Werror now. 5 more means now there are now 55. I think you must have misunderstood?

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?

Well, one of my main criticisms of pkgsrc is low quality packages. lang/pnet. The fact krb4 is still in here (apparently to save two obsolete chat programs). Demos from 2006. Unfinished games (e.g. xracer). Game demos. vlc08. I don't think pkgsrc is focused on quality because it's impossible to get this stuff thrown out. As I have said at least 3 times: There is not even a process that I can see to eliminate packages once they are in. You talk about quality but I don't think we're hitting the mark.

Nor do I think -Werror flag affects quality. The time for it is prior to release.

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

The point was that if nobody feels responsible for it, nobody will take the lead to keep it updated. Obviously there are noticeable exceptions, but those packages are so prominent they should have a listed maintainer.

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

I worked at NASA's Johnson Space Center Mission Control for 4 years. Bogus warnings were a daily occurrence for me. And we switch off the alarms if they squawk too much and watch the data (equivalent to watching the logs here.)

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?

Fixing package regressions.
You suggested that packages should be marked broken for DragonFly, at least if they were built with gcc4.7 (which obviously ignores any other platform using gcc4.7). However, with your logic, you should have said it should be marked broken for all platforms. Why penalize DragonFly for being the first the notice and emit a warning? Obviously the "problem" is invisible to the rest of the platforms, but it still exists. To mark it broken on DragonFly IGNORES and MASKS the now-known "problem" on all the other platforms.

There is no way you should have suggested that -- unless you feel, like Alek, that this is a DragonFly thing so it's our problem (which also points to the general feeling towards non-NetBSD platforms in general).

Or to really answer the question: Some of us don't think the Werror flag does all these indispensable things that you and Alek claim it does, and the pain of "fixing" it outweighs the loss of removing it.

Home | Main Index | Thread Index | Old Index