Re: sysinst split project - The Configuration File

[David Holland <dholland-current%netbsd.org@localhost>]

(from a while back)

On Wed, Dec 16, 2009 at 06:19:53PM -0200, Silas Silva wrote:
 > On Wed, Dec 16, 2009 at 03:12:07PM +0000, David Holland wrote:
 > > It seems to me that there are at least three different questions here.
 > > [...]
 > > The second is: whether it should be possible to direct the overall
 > > progress of the install process using a user-supplied script, which
 > > e.g. plugs together components of sysinst and executes them.
 > 
 > I think I didn't got it right (mainly because of my poor English
 > understatement :-[), but what you mean here? That people will call
 > sysinst functions (components?) to achieve something?

It is a push/pull issue, basically.

The way sysinst works right now, you start it, and from time to time
it asks the user questions.

One way to automate this is to set it up so you start it, and from
time to time it calls hooks in the sysinst automation script to ask
questions; the script figures out the answer and returns control.

The other way is to set it up so you start the automation script, and
it calls into sysinst to do stuff, telling sysinst exactly what to do,
and sysinst never calls back to ask questions because the answers have
been passed to it already.

Since programming with callbacks is usually troublesome, the second
architecture is probably preferable, as long as it doesn't become
insanely complicated or make the automation script into a large piece
of boilerplate that one customizes by making tiny edits in exactly the
right places.

 > If Lua was used, the configuration file could be expressed as a set of
 > tables, much like static data. The advantage of this approach is that,
 > before (or in the middle, or after) tables definition, people can call
 > anything in lua.

Right. The disadvantage is that it isn't static data, which means that
you give up the possibility of having tools to adjust/edit/munge it.

Many other environments have been set up so that there's an editing
tool, but the editing tool only works on the default form of the data;
if you make valid edits that don't fit what the editing tool
understands, the editing tool then loses badly. This approach is
unsafe and I (strongly) think we need to avoid it, both here and
elsewhere in NetBSD.

Even if nobody's going to be writing tools, Turing-complete
configuration is still undesirable, because it allows the creation of
setups that cannot be understood. And I don't agree that "just write
static tables and don't put code in" is an adequate solution unless
something is checking that the tables are really just static tables.
Sooner or later, someone will put code in, and subsequently (probably
not right away) get into trouble.

In general, we tend to express things as code when we haven't yet
figured out how to express them without needing code. For something
like install configurations we ought to be able to figure this out.

 > > The third is: whether pieces of sysinst itself should be written as
 > > scripts, and if so, whether part of the available configuration
 > > process should involve editing those scripts.
 > 
 > I think that depends on whether or not a script language will be adopted
 > in base.

I think that's the other way around. If there's a compelling case for
scripting installs in Lua, we'll get Lua.

-- 
David A. Holland
dholland%netbsd.org@localhost