[ tech-net suppressed, it's out of topic for this list now ]

On Thu, Aug 07, 2003 at 04:49:46PM +0200, Rogier Krieger wrote:
> Hi there Manuel,
> 
> thanks for the swift reply. I'm afraid I do not fully understand the
> solution you present, though. Probably due to my lacking
> understanding of the build.sh script.
> 
> So far, I have only used the build.sh script to generate a toolchain,
> but browsing through it, it seems capable of doing much more.

Yes, it can build a full release, including the tgz sets, bootable install
floppy, etc.
Look at the BUILDING file for documentation about build.sh

> 
> Do you suggest using build.sh to rebuild the entire system
> (including userland) and then working my way with the SA's?

Yes. Because it builds in its own tree, you won't have problems with
includes or libraries out of sync.

> 
> Every now and then, I come across minor build problems applying
> SA's, so perhaps I am consistently doing something wrong or
> missing out on something. Sometimes it may be the 'includes',
> at other moments it may be a library dependency.
> 
> If using a full system rebuild is not what you suggest, is there a
> foolproof way of keeping a source tree up-to-date while being
> ready to apply the security advisories verbatim? So far, I use
> various make commands. Should I switch to the build.sh
> script and if so, how should I invoke it?

Yes, you should. It's much easier.
Here is the command I use for i386:
./build.sh -m i386 -U -M /local/pop1/bouyer/tmp/i386/obj -D /local/pop1/bouyer/tmp/i386/dest -R /local/pop1/bouyer/tmp/i386/rel $*

You don't need to be root to run this.
The object files are built in /local/pop1/bouyer/tmp/i386/obj, the
binaries are installed in /local/pop1/bouyer/tmp/i386/dest *without the
proper permissions*, so don't use /local/pop1/bouyer/tmp/i386/dest
as a template to install binaries, and the release sets are in
/local/pop1/bouyer/tmp/i386/rel. I then extract the tgz sets in /
(excluding etc.tgz of course, which I extract in /tmp, and run
./etc/postinstall -s . -d / fix 
from /tmp).

> 
> So far, I have the following procedure in place:
> 
> + CVS checkout
> 	cd /usr
> 	checkout -r netbsd-1-6 -P src
> + Create object directories
> 	make obj
> + Toolchain build
> 	cd /usr/src
> 	./build.sh -t
> + Apply the security advisories from here on

Usually, the text in the security advisatory is for those who want to patch
their existing source tree, and not upgrade to 1.6.x_STABLE.
For example, you have 1.6.1 installed with the 1.6.1 sources extracted.
You want to fix the security problem *and only this*. For this the instructions
in the advisatory should work (applying the patch, or updating only the
files listed in the advisatory).
By checking out the netbsd-1-6 branch, you'll upgrade your whole system to
the head of the netbsd-1-6 branch. This is much more than the security fix,
and need a complete system rebuild.

> 
> As suggested in Ignatios' post, should I by default include the
> building of the various includes after building the toolchain?

In this particular case this should work, but for the general case
you may end up in a real mess, where the includes and libraries
are not in sync, and you can end up in not being able to build anything
any more. It's not trivial to recover from such a situation, you need to
know what exactly changed between the NetBSD version you're running and the
version you're building.
build.sh avoid this by building in a separate tree (the /local/.../dest in
my example). In fact, build.sh is a complete cross-build tool (I use it to
build for various targets from my dual-PIII box: sparc, sun3, sgimips, ...),
and as such doens't change anything to the running system.

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
     NetBSD: 24 ans d'experience feront toujours la difference
--