pkgsrc-Changes archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

On 10/12/2012 00:03, Aleksej Saushev wrote:
John Marino<>  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

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

Home | Main Index | Thread Index | Old Index