From owner-freebsd-hackers  Mon Nov 27 13:30:32 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id NAA29969
          for hackers-outgoing; Mon, 27 Nov 1995 13:30:32 -0800
Received: from multivac.orthanc.com (root@multivac.orthanc.com [204.244.20.2])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA29956
          for <hackers@freebsd.org>; Mon, 27 Nov 1995 13:30:26 -0800
Received: from localhost (lyndon@localhost) by multivac.orthanc.com (8.7/8.7) with SMTP id NAA21361; Mon, 27 Nov 1995 13:29:42 -0800 (PST)
Message-Id: <199511272129.NAA21361@multivac.orthanc.com>
X-Authentication-Warning: multivac.orthanc.com: Host lyndon@localhost didn't use HELO protocol
From: Lyndon Nerenberg (VE7TCP) <lyndon@orthanc.com>
To: "Amancio Hasty Jr." <hasty@rah.star-gate.com>
cc: hackers@freebsd.org
Subject: Re: Thoughts on the install and on Red Hat Linux. 
In-reply-to: Your message of "Sun, 26 Nov 1995 16:37:28 PST."
             <199511270037.QAA00537@rah.star-gate.com> 
Date: Mon, 27 Nov 1995 13:29:40 -0800
Sender: owner-hackers@freebsd.org
Precedence: bulk

>>>>> "Amancio" == Amancio Hasty <hasty@rah.star-gate.com> writes:

    Amancio> BTW: exmh has a cool installation procedure someone can
    Amancio> take a look.  Yes, I know that it is probably not a one
    Amancio> to one match to an OS installation however the overall
    Amancio> general procedure is cool.

Exmh has a rediculous installation interface that makes it impossible
to install using make. Why oh why do people insist on reinventing make?

Which is not to say that a tk script isn't a good way to build a GUI
install front end, let's just not generalize this to everything else
on the system, okay?

The proper way to do this is with a C library to manipulate the config
files, and curses and GUI (tk or whatever) frontends that do their
real work by calling into the install library API.

I've been investigating this approach as a way of automating the configuration
of the firewall systems I sell. What I have scratched out on paper is a
/config directory that contains the system configuration information
in a form easily parsed by software, a library to access the info, hooks
for the GUI (curses, command line, tk, whatever you like) to call the
library, and a set of scripts to take /config/* and generate the actual
system files.

This is still in the pen-on-paper design stage. Working code is a couple
of months away yet.

--lyndon