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

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

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

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

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

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.

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

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.

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

The list of supported platforms is published quarterly.

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

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

Except it is a hack and thus should not be applied blindly.

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

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.


-- 
HE CE3OH...