Date: Sat, 14 Jun 2014 21:10:40 +0200 From: John Marino <freebsd.contact@marino.st> To: Steve Wills <swills@freebsd.org>, marino@freebsd.org Cc: svn-ports-head@freebsd.org, svn-ports-all@freebsd.org, Oliver Lehmann <oliver@freebsd.org>, ports-committers@freebsd.org Subject: Re: svn commit: r357767 - head/net/cyphesis Message-ID: <539C9E30.2070505@marino.st> In-Reply-To: <20140614185459.GA68684@mouf.net> References: <201406141111.s5EBBCgV016094@svn.freebsd.org> <539C8682.3030603@marino.st> <20140614175243.GD67971@mouf.net> <539C8E46.1010803@marino.st> <20140614185459.GA68684@mouf.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6/14/2014 20:55, Steve Wills wrote: > On Sat, Jun 14, 2014 at 08:02:46PM +0200, John Marino wrote: >> On 6/14/2014 19:52, Steve Wills wrote: >>> Wouldn't the right thing be to mark it broken on FreeBSD 8 and 9 only, via >>> conditionals? >> >> >> No. >> If you were going to test for anything, you'd test for clang, not the >> platform. Secondly, what's the benefit of marking it broken? For >> people that try to build it via source? To save the builder the effort >> of trying? I don't think there's much benefit and in this case, >> there's a distinct downside. > > Well, first, I said that backwards... > > Second, sure, testing for clang is a fine idea too. > > Finally, yes, the benefit of marking it broken is all those things. Saving > build time on package builders is important. This breaks probably 1 second after configuration. What it saves builders is negligible. > Letting people know "yes, we know > this is broken" avoids confusion and lets folks search for things that are > known broken and fix them. I see it the other way. Marking it broken means no more logs. Eventually all the logs fall out, and nobody knows *why* it's broken. Some people actually put the broken part of the log in the commit message to document it, but that didn't happen here. So I am philosophically against a quick trigger on marking broken due to this downside. Sure, if it saves downloading a 100Mb distfile, it makes sense, but if it's a 89k distfile that breaks immediately, then let it keep breaking. I think it's ironic that the nuisance reports meant to spur the fix of a port actually resulted in the port getting marked broken on all platforms rather getting fixed on the problem platforms as was the intention. That certainly backfired! > What's the downside of testing for the compiler it doesn't work with and > marking it broken in that case? see above. > Also, would adding USE_GCC help here? >From what I could see of the build log, it should be relatively easy for a knowledgeable person to fix it to work on any compiler. A real attempt to fix it should be made before resorting to USE_GCC. But yes, USE_GCC would be preferable to BROKEN IMO. John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?539C9E30.2070505>