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

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

On 10/12/2012 00:03, Aleksej Saushev wrote:
> John Marino<netbsd%marino.st@localhost>  writes:
> > 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.
>
> It isn't clear what you call "state" above. The state of the world is
> that GCC 4.1 is definitly in field and I still expect GCC 3.4 being
> actively used on Solaris at least (I'm aware of SmartOS, but not every
> Solaris is SmartOS).

A bulkbuild report indicates the "state" of support on the platform, at 
least indicating what builds.

> Yes, we maintain pkgsrc on FreeBSD. At least I do, even though I do not
> maintain it proactively. It is usually enough not to break it intentionally.


I don't really consider this maintenance.  I too attempt to fix obvious 
errors in FreeBSD support when I run across it.  For my definition, 
you'd need somebody carrying a torch for FreeBSD similar to what I do 
for DragonFly and what Jonathan does for SmartOS to really qualify as 
maintained.  Again, MY OPINION.



> If a package builds, it doesn't mean that it works or implements
> reasonable subset of functionality. E.g. sysutils/libvirt on NetBSD,
> or editors/emacs* on NetBSD 6 (after removal of pseudoterminal nodes).
> Thus I do not see why just building packages keeps QA level.
> Even if you makes pkgsrc to run tests, many interesting packages either
> do not have them or do not pass all of them.

Here we are talking about different things.
I am talking about packages that have been tested on platforms that 
BREAK after an (often unnecessary) upgrade to the package.  This 
breakage should not happen.  If it's (A) known to work on platform X and 
(B) it has hundreds of packages that depend on it, you'd better damn 
well test it as thoroughly as possible.  If you aren't willing to do 
that, don't upgrade the package.  This "farm" would flag platform 
regressions.  Yes, it is really flagging whether it built or not, but 
the person proposing the change should not forge ahead when they know a 
platform suffers a build regression.


> The list of supported platforms is published quarterly.

I've seen that list.  It's "generous" in the sense that I mentioned 
before.  It's a list of platforms that pkgsrc will bootstrap on.


> > > 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.
>
> GCC 3.4 was the main compiler on Solaris at most a year ago.
> Note that it wasn't one of many GCC versions available, it was
> _the_ compiler unless you had access to SunPro.

I've got 5 Sunfire servers with solaris 10 in production since 2007 - 
although i always built with suns CC, never gcc.  Anyway, we're not 
disagreeing.  I believe my servers could run until 2020!


> > 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.
>
> Except it is a hack and thus should not be applied blindly.

A) I don't think it's a hack to turn this off
B) There may not be a choice barring the patching off source.  If 
-Werror is applied after CFLAGS, it's impossible to disable from the 
makefile.



> > 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.
>
> I don't see why it was a bad decision. If one follows that approach,
> one could easily assert that the whole NetBSD is badly designed
> since it uses -Werror for almost everything. I can't say much about
> DragonFly, but FreeBSD followed the same trend of raising warnings
> level.

Werror should be for DEBUG versions.  RELEASE shouldn't have it, for 
exactly this reason.  It's not future proof.  Yes, DragonFly also sets 
-Werror for world and kernel wherever possible, but that's for source 
under our control.  It's quickly turned off for third party software