From owner-freebsd-hackers  Wed Nov  1 12:42:19 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id MAA27150
          for hackers-outgoing; Wed, 1 Nov 1995 12:42:19 -0800
Received: from time.cdrom.com (time.cdrom.com [192.216.222.226])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA27145
          for <hackers@freebsd.org>; Wed, 1 Nov 1995 12:42:16 -0800
Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id MAA01241; Wed, 1 Nov 1995 12:41:59 -0800
To: Nate Williams <nate@rocky.sri.MT.net>
cc: grog@lemis.de (Greg Lehey), hackers@freebsd.org
Subject: Re: More nits 
In-reply-to: Your message of "Wed, 01 Nov 1995 12:40:02 MST."
             <199511011940.MAA15296@rocky.sri.MT.net> 
Date: Wed, 01 Nov 1995 12:41:59 -0800
Message-ID: <1239.815258519@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-hackers@freebsd.org
Precedence: bulk

> How about adding the noauto flag to the entry so that it won't get used
> on bootup.

I guess that's the best compromise.  I thought at first that "noauto"
hadn't made it into 2.1, so it didn't even cross my mind as an option.
However, I just checked and it's definitely in there so I'll use it.

Still, I think that the present situation remains sub-optimal in the
extreme.  The bootup *should not fail just because there's no CD in
the friggin' drive!*

> need of bash.  However, if you can think of an easy way of pointing
> folks to the 'standard' packages such as these I think Jordan would be
> willing to do the work if it isn't too hard.

What I would be willing to do is add the concept of "bonus packs" or
something where there are multiple, aggregated sets of packages loaded
as a group.  Anything less than this and there's no reason not to
simply use the package loading menu.  Anyone care to suggest some
standard sets?

> Actually, you *don't* use the same kernel for the floppy, since the
> floppy kernel contains the MFS image, while the disk kernel doesn't
> contain it.  It is possible (although improbable) that the disk kernel
> didn't get rebuilt.

I meant that that I use the same GENERIC base, which contains userconfig.
It's not an option you can turn off, after all! :-)

					Jordan