[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: pkgsrc/cross/mingw-binutils
On 10/11/2012 19:49, David Holland wrote:
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.
I still didn't see it. However, my point is still valid: without
regular bulk runs, there's no way to know the current state. A single
failure on a key package can easily kill more than 3000 packages that
depend on it. This point is really a tangent, but as I see it, there
are two sides to the coin. One can clearly install pkgsrc on FreeBSD
and use it, but is somebody really "maintaining" it? Had I stopped
checking after Q2, thousands of packages would have stopped building on
DragonFly for 2012Q3.
That leads to another tangent: No build farms. In an ideal (fantasy)
world, somebody would throw their proposed changed in a build farm and
ensure that no regressions (build failures) were suffered on any
platform. Pkgsrc BADLY needs something like this. I know it costs
money, I'm sure we could scrape together funds for a dedicated machine
but it still has to be hosted and controlled with other machines. I
don't see any talk about a facility like this, but I think it's
essential to keep QA levels up.
> 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.)
The current release of DragonFly, 3.0, also has 4.1. If I wasn't
already running 3.3, I could have checked with it.
But I think you're missing the "problem".
mingw-binutils didn't build on gcc47. I originally added a cflag
"-Wno-unused-but-set-variable". GCC 4.4 sees the flag, doesn't know it,
but lets it pass. Some unknown GCC older than that sees the flag,
doesn't not it, and chokes. The question is really: Which is the first
GCC that lets unrecognized warning flags pass?
> 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.
This is a consequence of not actually defining what pkgsrc pledges to
Since gcc 3.x still appears in the field, we need to continue to
You'll be able to find gcc 3.x in the field in 2020. I'm not so certain
"field" is the discerning factor here.
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.
It is good to know that disabling -Werror is fine. In fact, I think you
can make a case for not having it on any packages for the reason above.
GCC 4.8 is sure to break something that passes GCC 4.7.
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.
mingw-binutils isn't that old (version 2.18). It's only problem was a
bad decision to use -Werror. I don't think this package needs anything
else right now.
Main Index |
Thread Index |