Subject: Re: "make release" in /usr/xsrc
To: Simon Burge <simonb@netbsd.org>
From: Frederick Bruckman <fb@enteract.com>
List: tech-install
Date: 12/22/1999 03:24:34
On Wed, 22 Dec 1999, Simon Burge wrote:

> This looks pretty much ok to me.  The only thing I'd question is the
> checksums - why not just run the sums over all the .tgz files.  If you
> "make release" in xsrc twice you'd end up with two sets of X set sums...

Good point. I was hoping to save a little time, but I hadn't thought
of that. 
 
> Also, does the
> 	+ .include "/etc/mk.conf"
> 	+ BSDSRCDIR?=	/usr/src
> need to be before BSDSRCDIR is referenced?

Hmmm... No. Before a test, but not here. Evaluation of variables in
the target's shell commands is deferred until execution time. I don't
think it's really necessary to test for ${BSDSRCDIR}/distrib/sets,
either, which would require putting all that first. If we had to test
at all, I'd rather test for "sets" than for /usr/src (which could be
an empty directory or unmounted filesystem), but we don't really--the
resulting error if /usr/src is missing will be self-explanatory.

With that in mind, it would probably look better to set BSDSRCDIR
unconditionally at the top, and then have the "include" be the last
line of the file.
 
> Out of left field, what about treating xsrc sort of like crypto-*, so
> we'd have .../src/xsrc in the top level src tree?  I suspect it would
> also then be easier to get the src/Makefile "make release" target to
> DTRT with X as well.

You can't treat xsrc exactly like crypto-us. As far as I know, 
there is no U.S. xsrc repository, and "stitching" modules together
only works when they live on the same server.

More to the point, I don't exactly want "make release" in /usr/src to
reach into xsrc. The only change I want to see in /usr/src is for
"make release" (without EXPORTABLE_SYSTEM set) to build _only_ the
security set, as it doesn't even build the security set now, and the
sets is does build are not useable. The script I presented in an
earlier message could be called under "make fullrelease"--or something
like that--but the more limited release target is still useful.
Consider that you might want to build all three stages on different
machines: a non-crypto system just for the main part of the release,
other machines could build either flavor of the security set, another
machine could build just the X sets.