Subject: Re: pkgsrc vs mk.conf
To: Quentin Garnier <email@example.com>
From: Todd Vierling <firstname.lastname@example.org>
Date: 03/24/2005 18:33:12
On Thu, 24 Mar 2005, Quentin Garnier wrote:
> Until a few weeks ago when I was notified of an issue building
> net/netbsd-tap, I had never realised we were invoking builds with
> MAKECONF=/dev/null in the environment.
> The idea behind this is to prevent /etc/mk.conf from tampering with a
> compilation supposedly completely under the control of pkgsrc. I agree
> it is something we're very likely to want.
Not only is it wanted, it's a pretty solid requirement. To wit:
> However, the fix is not right, as it brings issue in the case of a
> completely legitimate (and very system-dependent!) build of a LKM.
> Then we have this package, which is a LKM specific to OtherBSD. As it's
> a very system-dependent package, it will use OtherBSD's make(1), and
> OtherBSD's make(1) configuration, possibly /etc/mk.conf.
> In that example, passing MAKECONF=/dev/null is _very_ wrong, as pkgsrc's
> settings and OtherBSD's settings simply cannot clash, the make programs
> are not the same and pull in different files.
No. If you need configuration bits to find the kernel source or somesuch,
that should be passed in to the sub-make manually as part of MAKE_ENV, so
that the environment of that build is well controlled.
If it's a LKM for OtherBSD, then the package's Makefile should take *only*
the bits it needs to build a LKM for OtherBSD and pass them in directly.
The process of extracting that data and handing it over to an "isolated"
make(1) invocation should be a trivial piece of glue.
See, the flip side of allowing any arbitrary mk.conf to a build is that you
*will* get (even in the case of a LKM) users setting options that cause the
pkgsrc build to fail in unexpected ways. The environment used to do the
sub-make invocation must be as isolated as possible from such variables.
> Of course, there should also be a way to make sure the native make(1) is
> used, because as of now, unless the package plays with definining
> MAKEPROGRAM directly, bmake(1) is called, and on OtherBSD, to build a
> LKM, it is likely to fail.
If it's an OtherBSD LKM, that is certainly a candidate for redefining
MAKE_PROGRAM right in that package's Makefile.
-- Todd Vierling <email@example.com> <firstname.lastname@example.org>