Re: Configuration management, revision 3

[Joey Hess <joey@kitenet.net>]

Martin Oldfield wrote:
> Isn't the obvious generalization to divide configuration questions
> into blocks, then specify a state machine to navigate between blocks ?
> 
> I think it would be good tohave a very general verification mechanism:
> were we to implement this in perl, then we could just provide a chunk
> of code and eval() it.

That's actually a good summary of where I think we're headed. However, I
think you need to allow each package to provide a state machine. We need this,
becuase there's no way some generic state machine is going to be able to 
present the data to the user in a consitent and understandable manner. A
user expects to see a logical sequence of questions. If each package
provides its own state machine, then the maintainer can make sure the state
machine always presents the set of questions is a logical squence. So I think 
you should change it to this:

  The obvious generalization is to divide configuration questions
  into blocks, then allow each package to specify a state machine to 
  navigate between blocks. Also, allow data verification using chunks of
  some programming language.

The only problem we have now, is that many package maintainers arn't too
comfortable writing state machines. We aren't all computer scientists. Also,
you already conceeded we need to use something else for data verification [1].
So, why not replace the nice deterministic state machines with something a
little messier, like a shell script.

  The obvious generalization is to divide configuration questions
  into blocks, then allow each package to specify a shell script to
  navigate between blocks, and do data verification.

Suprise, this is exactly my v4 version of Wichert's proposal + Antti-Juhani
Kaijanaho's data structures proposal (the two can be merged easily).

I don't understand why people in this discussion have been so opposed to
using standard programming languages. We use them all the time in the
existing maintainer scripts, and we _will_ need their flexability here too.

-- 
see shy jo

[1] If we were all computer scientists, we'd know you could use
    a state machine for that, too. ;-)


--  
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org