Subject: Re: The future of MAKE_JOBS
To: Joerg Sonnenberger <>
From: Jeremy C. Reed <>
List: tech-pkg
Date: 06/13/2007 12:49:19
On Wed, 13 Jun 2007, Joerg Sonnenberger wrote:

> Hi all,
> I've talked about it during pkgsrcCon and with various other developers.
> In short, I strongly dislike the current way MAKE_JOBS is handled.
> (a) For most packages it is like playing Russian roulette.
> (b) The default is "supported", even without any knowledge of how
> subtile it can break a package.
> (c) It doesn't work for most of the larger packages.
> The point of having the feature is defeated by (c) as those packages,
> where you really want to have it, don't work with it. (b) is a policy
> question. I demand at least to change the default to "no" aka don't
> assume that a package supports it.
> Even if a package builds fine with -j4 or -j8 on a dual cpu box, it can
> fail on a different system with more / less CPUs or different
> scheduling. It is really hard to write correct rules for that, just look
> at the issues NetBSD base had over time. Given that I am a strong
> opponent of reliable and reproducable pkgsrc builds, I find the current
> status very unsatisfactional.
> For that, I want to see this issue resolved to either change the default
> of MAKE_JOBS_SAFE to "no" and have any request to change that for a
> package be backed by some reasonable evidence, or to see it removed
> completely. 

I consider this feature similar to USE_ABI_DEPENDS=no. We don't support 
USE_ABI_DEPENDS=no other than if that finds a wrong ABI_DEPENDS dependency 
which we can update. We don't allow USE_ABI_DEPENDS=no for official 

MAKE_JOBS is not documented, so maybe we should document it with a 

And maybe PKG_DEVELOPER could imply default MAKE_JOBS_SAFE=no?

While agree we can't support MAKE_JOBS, I don't see what is wrong with 
someone to choose to use it. Some have reported that it works for them in 
their environments.

If they default is changed, that will be fine with me as long I can 
disable that change.

I don't want it removed though.

  Jeremy C. Reed