[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
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
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.
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
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.
Main Index |
Thread Index |