From owner-freebsd-current@FreeBSD.ORG Mon Jun 20 18:54:45 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CCF316A41C; Mon, 20 Jun 2005 18:54:45 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-66.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id C220543D1F; Mon, 20 Jun 2005 18:54:44 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j5KIrVtX026513; Mon, 20 Jun 2005 12:53:33 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 20 Jun 2005 12:54:52 -0600 (MDT) Message-Id: <20050620.125452.102654445.imp@bsdimp.com> To: deischen@freebsd.org From: "M. Warner Losh" In-Reply-To: References: <66959.1119209763@critter.freebsd.dk> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: phk@phk.freebsd.dk, rwatson@freebsd.org, current@freebsd.org Subject: Re: Summary: experiences with NanoBSD, successes and nits on a Soekris 4801 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2005 18:54:45 -0000 In message: Daniel Eischen writes: : On Sun, 19 Jun 2005, Poul-Henning Kamp wrote: : : > In message <20050619155228.Y6413@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