> I guess my main point is that we try to do something now where one
> technique fits all (groveling in the symbol list). I think to do things
> "Right," we need to do something different, and probably will end up
> needing two ways to do things.

Up until now I would have responded to this with "Strongly Agree".

However I am beginning to suspect that the real solution involves revving
userland alongside the compiler.

Suppose I mv /sbin to /sbin-1.3.2 and link /sbin to it. Then I build sbin
in -current and install it to /sbin-current. I could do the same thing with
/netbsd and other directories, and have scripts to switch between them:

	# switch to -current; lots omitted for clarity
	for x in /netbsd /lib /bin /sbin
	do
		rm $x ; ln $x-current $x
	done

This has some limitations though. Maybe a more drastic solution is in order:
add a boot option that chroot's to a directory before loading /netbsd and
the booted kernel uses that directory as root. This forces me to switch the
whole system at once, but there's very little chance of a screwup trashing
my "main" installation or any other "sub" installations that I have built.

So when I want to move up to -current, I sup everything and tell the build
system where my "root" directory is, and let it chug to populate the entire
directory tree. I should be able to NFS-boot another machine from that tree,
or reboot my own machine into that tree using the new boot option.

If we can allow read-only mounting of the original root disk, it would enable
the new configuration to be debugged with substantial access to the resources
of the "main" installation.

This is fine as long as a "main" installation can build -current. But when
there are incompatible revisions to the toolchain, things get sticky. I am
not updating a shared libc on my 1.3.2 system just so it can build -current.
That is totally preposterous. Instead we should MAKE CROSS COMPILATION WORK.
EGCS supports it, because Cygnus has lots of customers who manufacture bare
systems with little or no O/S.

For example, it is very possible to construct a package that provides a self-
contained "egcs-1.3F" toolchain, complete with headers and libraries. Sorry,
that should have been "egcs-1.3F-i386" or "egcs-1.3F-arm32" or ...

Of course this method will fail when the -current toolchain adopts a radical
change which requires something too recent. As the doctor said, Don't DO that.

Todd Whitesel
toddpw @ best.com