Re: Summary: experiences with NanoBSD, successes and nits on a Soekris 4801

From: Poul-Henning Kamp <phk_at_phk.freebsd.dk>
Date: Mon, 20 Jun 2005 21:25:36 +0200
In message <20050620.125334.10575355.imp_at_bsdimp.com>, "M. Warner Losh" writes:

>The big problem is that there's not a build environment separate from
>the install environment.

I'm not 100% sure I know what you mean here...

>At work, we created a system that has this
>separation, and it has proven invaluable.  The current NO_FOO knobs
>aren't useful in the BUILD phase, bare are moderately useful in the
>install phase (we actually go a step further, and just have a list of
>directories to do an install from).
>
>This is the single reason that I've not pushed to migrate our build
>system at work to using nanobsd as its base...

It's worth noting in this context that not even "make release" uses
an unadultered installworld, but instead has to use the pseudo-magic
"distribution" target followed my manually frobbing the resulting
tree.

The biggest problem however is not the 'how' but the 'which' question.

Take /usr/share/man/man1/gcc.1.gz as an example.

That file should not be installed if the user has specified any
single one of:

	NO_GNU		# No GNU license code.
	NO_GCC		# No GNU Compiler
	NO_CC		# NO C compiler
	NO_TOOL_CHAIN	# No compiler tools at all
	NO_MAN		# No manual pages
	NO_CPP_RT	# No C++ runtime
	NO_ROFF		# No troff tools
	NO_GROFF	# No GNU groff
	NO_MDOC		# No mdoc macro package

	(NB: Deliberate exaggeration for illustrative effect)

The src/release/Makefile is a good example of why Makefiles is not
the right technology to implement conditional behaviour in this
level of detail.

The ideal solution would be to have complete awareness of the
actual dependencies (as a combination of explicit entries and
makefile derived information) but unless a exhaustive programme
of tinderbox tests were instituted, the manually maintained
dependencies would not be correct most of the time.


And I will also echo the previously expressed sentiment that this
is not to domain area to over-engineer a solution.

Right now there is a $24 retail price difference between the smallest
CF card I can buy (128M) and one that can contain a non-reduced
nanobsd installation (512M).  There are templates in the nanobsd
sources for media sizes down to 64M for people to start from.

I'm not saying that the problem is entirely solved, we are 90% of
the way there now, and the last 10% may simply not be worth it.


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
Received on Mon Jun 20 2005 - 17:25:51 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:37 UTC