jmmv
pkg_comp should override pbulk's multi-package default
What I did: following the recent howto, updated my 1.x config to 2.0 and ran my usual weekly pkg_comp build.
What I expected: roughly the same set of binary packages as last week's pkgtools/pkg_comp1-powered build, including lang/php56 and a handful of extensions.
What happened instead: the same binary packages plus lang/php70 and extensions built against it and lang/php71 and extensions built against it.
Why it got in my way: my little script to pkg_add everything failed due to conflicts between the various PHP versions.
What fixed it for me: adding NO_MULTI_PKG= #defined to extra.mk.conf so that pbulk only builds the PHP I asked for.
What I'm suggesting for pkg_comp: set this variable by default, and probably don't even worry about needing to allow it to be overridden by the user. As far as I can tell, the default behavior makes sense for typical pbulk usage but is never desirable in pkg_comp usage.
I had this same problem (and in fact the PHP 7 builds were failing but the overall build still declared "success!"), but it didn't end up getting in my way because of my fancy install script only tries to install the packages that I explicitly requested.
Aha! Thanks for tracking that down. I think I encountered this at some point but assumed that this was the price to pay for using pbulk. I'll add a NO_MULTI_PKG override to the default mk.conf. Users can always "undo" the override in their own extra.mk.conf.
Do you know of any "simple" package that triggers this behavior? Would like to add a test for this, but building PHP altogether takes too long :-/
I haven't tried to use this to reproduce, but www/lighttpd has a lua option.
Update: it indeed needs to be overridable. pbulk was briefly giving Unresolvable dependencies for py-libxml2 and py-expat in my builds because apparently NO_MULTI_PKG means two things, one that I expected and one that I did not:
- (Expected) Don’t volunteer to build every version of every multi-version package
- (Unexpected) Don’t permit dependency traversal to build a second version of any multi-version package
FWIW, I chose to keep NO_MULTI_PKG and instead add PKG_OPTIONS.harfbuzz+=-doc to avoid anything bringing in python27 when python37 is the default. This probably isn’t tenable in the general case. But neither is (1). Probably we need a way to tell pbulk to do (1) without also telling it to do (2).