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

[Aleksej Saushev <asau%inbox.ru@localhost>]

John Marino <netbsd%marino.st@localhost> writes:

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

I don't see how the lack of report on build state of thousands of little
used (perhaps even unused) packages can indicate the state of support.
(Or are we talking about non-monotonic logic here?)

>> 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 most of user-visible packages build fine, I consider it supported,
whether there was bulk report in recent few years or not. I do not
restrict myself to proactive support. In many cases it isn't much
useful and doesn't pay off (considering the amount of resources to
spend just to make sure that some packages build).

>> 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 problem here is that you do not see all internal packages that
depend on visible ones. Sometimes they do not even exist in the form
of pkgsrc packages.

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

Given that bootstrap involves building of about five packages,
this is enough to make some claims.

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

Instead of letting package fail when it might be in danger of losing its
functionality, you let it build with potential errors. Thus it is a hack.

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

I don't see why -Werror should be for debug versions. It doesn't affect
run time but it makes sure that released package doesn't contain code
of certain (inferior) quality.


-- 
HE CE3OH...