Re: CVS commit: pkgsrc/cross/mingw-binutils

[David Holland <dholland-pkgchanges%netbsd.org@localhost>]

On Wed, Oct 10, 2012 at 05:38:39PM +0200, John Marino wrote:
 > The next bulk build report from either FreeBSD or OpenBSD (any
 > release) that I see will be the first.  It's very generous to call
 > these platforms "supported" by pkgsrc.

Not long ago there were no regular bulk build reports of any kind
except for the stable-branch NetBSD package builds.

Anyhow, the last FreeBSD bulk report I see was posted in April. Yes,
that's six months ago, but that's hardly a long time.

 > Also missing the point: Nobody pointed at GCC 4.2 as the problem.

That would require knowing offhand which gcc version the warning flag
was added to (not likely) or having a stable of already-built gcc
versions to test (also not likely) -- like many people here the only
gcc versions I have readily available are the 4.1 from netbsd-5 and
the 4.5 from netbsd-6 and -current.

(Actually I can also get to a 4.1 shipped by Red Hat, and I might have
a 4.2 somewhere on a machine that's powered down.)

 > I think the project should define what platforms and compilers are
 > protected (supported) leaving the rest as "maybe it will work,
 > maybe not".  These seem like very basic parameters to me.  If this
 > already exists, how about a link?

This list already exists (there's a list of OSes, the compiler list
follows from it) but this suggestion is missing the basic point, which
is that there is no time when it's appropriate to tell someone whose
world you've broken to suck it.

Since gcc 3.x still appears in the field, we need to continue to
support it.

This whole thread is also missing another point, which is: new gcc
versions routinely break builds, particularly of low-quality software.
As long as gcc remains the predominant compiler, affected packages
will get fixed upstream, so these problems are transient, and
disabling -Werror in the meantime is a perfectly fine approach.
Or one can do the fixes and send them upstream.

Affected packages that are not maintained upstream should be either
patched or marked broken and eventually removed, depending on how
valuable they are and if anyone's interested in tidying them up.

I don't know which of these cases applies to mingw-binutils.

-- 
David A. Holland
dholland%netbsd.org@localhost