>>>>> "RGR" == Richard G Roberto <[EMAIL PROTECTED]> writes:
RGR> This sounds similar in principal to what I've been proposing RGR> for almost two years on this topic (even before this list was RGR> created). I'm glad someone else also sees some sense in this approach; I was starting to wonder :) RGR> Can this be re-worded into multiple phases that we RGR> can start refining in discussion? How about this - it isn't particularly well fleshed out, but I think it touches on most of the high points. 1. implement a mechanism to replace all config queries from packages. Status: done (modulo more stringent error checking in the script) Visible effect: zip Benefits: provides the important first step in abstracton. 1.x. (optional) implement alternative front ends for user interaction Status: not started Visible effect: looks prettier Benefits: none, except to dribbling idiots that insist on having a colourful configuration phase which sucks their CPU dry. This doesn't actually make the configuration any easier or add any functionality. 2. add some useful functionality, such as question priorities and defaults Status: well, we have a couple of ideas on what useful functionality we would like to see... Visible effect: depends on exactly what is implemented, but the two above will allow the option of trimming down configuration stages, at minimum. Benefits: aside from the obvious, this is the first proof of concept phase. If this yields tangible benefits, then it can be floated as a serious proposal for maintainer comment. 3. implement alternative backends to store configuration data. Status: none to speak of Visible effect: how far can we take it? Possibly to completely hands free installation, if we can use DHCP to boot a cluster and some kind of auto-discovery method to find the config db. In real terms, simplifying installation down to configuring the network, apt'ing a local meta-package, and pointing the configuration engine to a local config db. 4. less is more. Once crude hacks have been removed from package configuration, we can look at more elegant ways of doing what we need to. One example is centrally distributing not merely single items of configuration, but serving out config files en masse. Status: pipe dream Visible effect: probably nothing Benefits: obviously depends on exactly what we wind up doing. With regard to variable substitution in conffiles, if an item of configuration data is used only by one package, there is little point in breaking it up into pieces, since they aren't likely to have any semantic value on their own. This will save having to write additional code and sanity checking for each individual config file that is shipped. RGR> Even if this bit is totally transparent to the way it RGR> works now, we'll have achieved getting the abstraction in RGR> there to work the other phases. Can this be as simple as RGR> having an intermediate script simply take questions from a RGR> package installation script, present them to the user, get RGR> the user's response(s), and provide the answers to the RGR> package installation script? Yes, I've already written and posted a sample implementation of this. RGR> Once that's done, we'll have something to show the other RGR> developers. It would of course be a good idea to fully flesh RGR> out the other phases so we can decribe the full project. It RGR> may be difficult to get buy in from people if all we had was RGR> this first bit and a bunch of loose ideas about what to do RGR> next. Bah, humbug :) m.