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

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

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


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


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.