> > 	Also, why is there a fundemental dependancy on the GNU info system
> > 	to bootstrap NetBSD 1.4?
> 
> The GNU people more or less force us to (indirectly: for some tools there isn't
> any up to date manual page).
> 
	Fine, but why must it be part of the bootstrap, especially when the
	MKMAN=no directive is turning off man page creation!

> I suggest you build and install new kernel with COMPAT_13, build and install
> libs, then build and install the info system, then make build.
> 
	Execept the 1.4 kernel doesn't work on my stock 3000UX, it hits the
	presumed pool panic that the sun3 and Next m68k ports have seen as
	well. How any Amiga could last long with a 1.4 kernel and not hit
	this is strange; am I the only Amigan left with only 16M of memory?!

> Sorry if I sound nasty, but if you're running NetBSD-current, you're supposed
> to read -current and act upon it, or figure this out yourself. If you just
> want to upgrade to 1.4 painlessly, wait for the 1.4 release or at least the
> 1.4_BETA snapshot. I would not advise you to try the _ALPHA. This is
> experimental software and you're supposed to find and report and if possible,
> fix problems.
> 
	Been reading -current or its equivalent since before the Amiga port
	was sync'd to the main tree; i.e. Markus Wild's original port work.
	Since I'm reporting it I DID figure it out for myself and am wondering
	why such a dependancy is in the initial bootstrapping when it doesn't
	strictly need to be and may trip up those less familiar with the
	historic build process.

	I'm commenting on 2 problems:
	
	One is an irritation (info being part of the bootstrap)

	One is is a major build stopper; the pool related panic that I need an
	updated ddb backtrace code to track down properly; since
	the sun3 and Next ports are seeing it as well I'm willing to bet it
	was some of the recent pool/memory changes that went in just before
	-current became 1.4_ALPHA.

> I don't believe you were able to go from 1.2 to 1.3, or from 1.1 to 1.2, by 
> just doing "make build".
> There were compiler/linker/yacc/lex/shell/make changes, that required to 
> carefully follow steps explained on the NetBSD-current mailing list.
> 
	Yep, and many times the order wasn't even explained in -current; you
	were just supposed to know.

	But none of those transitions included the extraineous inclusion of
	excess software like the 1.4 transition is going to require; i.e.
	the info subsystem which might also clash with already locally
	installed versions of the program in /usr/local...

> > 	The suspected pool panic has stopped the process for now but I'd still
> > 	would like to know why the build process for BSD now has an extra GNU
> > 	dependancy that it doesn't REALLY need... B^(. Can we add a
> > 	MKINFO=no or something to the basic bootstrap to forego the need for
> > 	info during initial bootstrapping?
> 
> If you don't want to do the manual procedure I explained above: add it
> yourself, bootstrap, then remove it and build again.
> 
	The panic precludes using a 1.4 kernel so I'll have to go as far as
	I can on a 1.3.3 kernel although the libc changes will probably
	torpedo that; the 1.4 make is dependant on the new vfork so 1.3.3
	chokes on its compile.

	I've done many manual upgrades and figured out many twisted install
	procedures in previous releases; what I'm questioning here is the
	NEED for the GNU info system on a bootstrap process.
	
	There didn't used to be the REQUIREMENT for GNU info, someone added it
	without adding a way to disable it for the initial bootstrap phase;
	i.e. there is no MKINFO=no capability as far as I can tell for the
	ecgs and other bootstrap phases.

	It may seem like a picky point but if we let GNU info slide by for 1.4
	what's next? Will we require half the pkg tree in 1.5 to do a
	1.5 bootstap?!

	Hopefully with the ddb tweek it will be straight forward to track
	down the pool panic problem and get the 1.4 kernel to stay up.

	Considering I have a 16M 100% stock 3000 I'm surprised other Amigans
	haven't run in to the panic, it hits as soon as UVM needs to start heavy
	paging.

		-Rob