Date: Wed, 4 Sep 2013 14:00:30 +0000 From: Alexey Dokuchaev <danfe@FreeBSD.org> To: Stephen Montgomery-Smith <stephen@missouri.edu> Cc: svn-ports-head@freebsd.org, svn-ports-all@freebsd.org, Stephen Montgomery-Smith <stephen@FreeBSD.org>, ports-committers@freebsd.org Subject: Re: svn commit: r326241 - head/math/octave-forge-odepkg Message-ID: <20130904140030.GA37324@FreeBSD.org> In-Reply-To: <5227293D.30108@missouri.edu> References: <201309040138.r841cHYC074414@svn.freebsd.org> <20130904033030.GC71557@FreeBSD.org> <5227293D.30108@missouri.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Sep 04, 2013 at 07:36:13AM -0500, Stephen Montgomery-Smith wrote: > However, from a philosophical point of view, if a project external to > FreeBSD makes source code that is not safe for the -j option to be used, > should FreeBSD ports committers feel that it is our job to correct their > source code? This is a question of how far we, as a distributor (packager) of software, want to go in trying to make it perfect. I view upstream tarballs as raw material, and rarely all it takes is to simply run ./configure && make && make install to give our users (of both packages and ports) something close to perfect. One might think that we should care about run-time issues, but Debian for example often goes down to fixing spelling mistakes in manpages and documentation, and they even write missing manpages themselves! I am very much charmed by this kind of attitude. I think we can do the same. Build times matter for people who maintain their installed software with ports, and personally I hate to see my quad CPU being 75% idle because I was too lazy to properly fix (from what I see, in most cases it is fairly easy to do) some port. We could well just mark ports as jobs unsafe and report the problem to the upstream. The thing is that just like we don't like PRs without patches, upstream also gets more eager to work with bug reports that provide either working solution, or at least some helpful analysis. This is especially important to FreeBSD (and other less-popular-than-GNU/Linux systems) as it helps to increase awareness of FreeBSD as not just friendly and supportive community, but also a nice operating system to develop software for. Most people develop on and for GNU/Linux; bug report without a patch for "some BSD thingy" is more likely to be ignored (vs. bug report without a patch, but for GNU/Linux). That said, I'm joining John is his reply: try it, see if the -jX problem's simple of not. Maybe the fix is trivial (it happens more often than one might think). If it's hard, google it: chances are that the patch already exists and floats on the net; check upstream github, etc. These kind of background checks won't eat too much time. If the problem deems hard, oh well, there is always MAKE_JOBS_UNSAFE. ./danfe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130904140030.GA37324>