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

From: M. Warner Losh <imp_at_bsdimp.com>
Date: Mon, 20 Jun 2005 12:54:52 -0600 (MDT)
In message: <Pine.GSO.4.43.0506191610170.7472-100000_at_sea.ntplx.net>
            Daniel Eischen <deischen_at_freebsd.org> writes:
: On Sun, 19 Jun 2005, Poul-Henning Kamp wrote:
: 
: > In message <20050619155228.Y6413_at_fledge.watson.org>, Robert Watson writes:
: >
: > >I general, I was quite pleased with the experience.  NanoBSD is fairly
: > >straight forward to configre and adapt.
: >
: > I'm still not satisfied with the nanobsd config/customize process,
: > ideally I would want to have only a single file with a sensible
: > format control the nanobsd build process.
: >
: > The major obstacle is the "cutting things down to size" process
: > using NO_FOO options.
: >
: > In order to get down a 31MB partition size things have to be cut
: > very extensively and not even the NO_FOO options is enough at that
: > level but sniper rm(1) commands are necessary.
: >
: > I think the NO_FOO options is the best compromize, but we need them
: > to be more aligned to user concepts, "I don't need a compiler and
: > all that", rather than "Don't build the C++ compiler and hobble
: > the build because of this".
: 
: How about NO_FOO[_INSTALL], where NO_FOO = no build and no install,
: and NO_FOO_INSTALL just prevents the install.  In theory, you could
: build the complete system, then use NO_FOO_INSTALL instead of rm(1).

What's wrong with making sure that NO_FOO will work in the install
case to not install foo when it is set, even if it was unset in the
build process?

Warner
Received on Mon Jun 20 2005 - 16:54:45 UTC

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