From owner-freebsd-install Fri Feb 13 15:34:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA03847 for freebsd-install-outgoing; Fri, 13 Feb 1998 15:34:47 -0800 (PST) (envelope-from owner-freebsd-install@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA03835 for ; Fri, 13 Feb 1998 15:34:44 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id PAA05166; Fri, 13 Feb 1998 15:33:54 -0800 (PST) Message-Id: <199802132333.PAA05166@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: dag-erli@ifi.uio.no (Dag-Erling Coidan Sm rgrav) cc: freebsd-install@FreeBSD.ORG Subject: Re: Questions to the gurus :) In-reply-to: Your message of "13 Feb 1998 17:18:29 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Fri, 13 Feb 1998 15:33:53 -0800 From: Mike Smith Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id PAA03837 Sender: owner-freebsd-install@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On the functional side, I'm thinking about a system of .inf files > which specify the name, location and size of each distribution, as > well as the long description, dependencies etc. (hmmm... perhaps we > could even use the pkg format for the distributions...) With some > minor work, this could mean that a single boot floppy could be used to > install any version of FreeBSD. If the floppy is older than the > version you want to install, you can just download the .inf file... Sure. But you're not going far enough. I'm not really ready to release this, but holding it back longer will not help the cause any more than putting it out for wider scrutiny. Please find attached an early draft of a document describing parts of the new package scheme. Some relevant issues that may not be obvious from the document: - Packages are shipped in Zip-format files. We have a contributed library that allows us to work on these directly, without needing to unpack the entire package somewhere first. - The base operating system will be packaged using this scheme. - There will be a database backend responsible for tracking package(s) owning file(s).a - The install scripts packaged with the base OS components will be responsible for installing the components. Non-component setup will still have to be handled by the installer. > Same goes for support for serial consoles of varying arcanity > (arcaneness? sp?) - I think sysinstall should support as many > terminals as possible (headless We have a couple of UI options currently under consideration; Borland's TurboVision is one, there is another, hopefully friendlier, UI under development by another contributor. We expect to see an early cut of this in a week or so. There has been not inconsiderable discussion about using a diagrammatic rather than procedural path through the installer, somewhat akin to the way that InstallShield behaves. A document describing this is currently outstanding. > How concerned should I be about screen size? Can I safely assume no > resizing will take place? Can I safely assume that the screen will be > at least 60 columns wide, and at least 15 or 20 lines tall? Expect that 80x24 is the limit. > Is libdialog a big win, or is it OK to code directly against > libncurses? Avoid interminging UI code and backend code. > More questions will come when I think of them... If you want something really helpful, very important, and likely to result in lots of discussion and a strong ongoing commitment, might I humbly suggest that you install everything from a recent 3.0 snapshot on a fresh machine (or some other equivalent technique), and start dividing the base operating system into categories? By this I mean make a list of individual *files* that comprise each category. I would suggest the following categories: - base Base system components required for operation - devel Compiler, linker, headers, static libraries, etc. Subdivide into devel-base, devel-c++, devel-objc, etc. - text Text processing tools (*roff, etc) - manpages Subdivide into manpages-base, manpages-devel, etc. as starters. I'm sure you can come up with more. There are also obviously dependancies involved too. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-install" in the body of the message