Joey Hess <[EMAIL PROTECTED]> wrote: > 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.
Note that most packages do not require such a state machine. I'm not convinced that installation scripts are the right place for packages which do require such complicated configuration. As a general rule, when configuration gets that complex you're going to want to use the same tool for reconfiguration. For the case of bulk installation (many machines being configured) you only need to provide for the simple case. It's probably sufficient to provide for one or two simple cases, then also give the *option* of running some smarter program at postinstallation time. Then again, for networked installs of these cases you probably want to be able to use some pre-built configuration file as the surrogate for actually running the program interactively. Finally, I don't think we can completely get rid of interaction with the user at install time. But what we can and should do is provide a reliable way of anticipating that such interaction will be necessary (and always a way of arranging things so that it doesn't need to be done each time if you're installing a hundred systems). -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
