I've been reading this discussion, and we seem to have jumped past a couple of important structural questions (I think we already know what problems we're trying to solve).
The questions I can think of are: I. How is amalgamation of data from various sources done ? Is it done at the time the package is installed (ie, data is requested from the configuration manager), or is it done earlier when the sources are specified. I can see at least the following two models: (a) There is a single database in /var or /etc with all the configuration data. This acts as a cache for already-entered data, a temporary store for data which was prompted for before installation started, and a long-term store for questions which shouldn't be asked again on upgrade. If it is desired to load configuration from another system or a preprepared file it is preloaded, like a cache. (b) There is a configuration file giving several databases, many of which will be read-only, and zero or one of which are read/write or write-only. At the time a package is installed the different data sources are consulted and the right data is chosen. I don't like (b), and can come up with at least these reasons: (1): (b) is much more complicated to implement. We have to (for example) generate a configuration file syntax, and write code to explictly select which data to use explicitly. If we do (a) we only have to have a merging program which can be told whether to prefer old or new data, and the config manager core need not know about data sources. (2): (b) makes it hard to overwrite a whole category of data. For example, supposing I want to say `discard all local config data for the MTA, and fetch it from <machine> instead'. With (b) I have to be able to express that in the config file syntax, and then delete it from the config file again later. With (a) that becomes an explicit operation. (3): Writeback. The config manager will have to write back the answers it gets somewhere so that the next installation won't ask the same questions again. This introduces a fundamental asymmetry in the design, because that data `source' can't be handled like the others. (4) Fundamentally, I just like caches in this context - they have the right properties, particularly the property that you have to be aware that the data might not be available and be prepared to acquire it or fail. II. Where are the questions `defined' ? Many of the proposals that I've seen so far have a fixed list of questions in a file. I don't think this is at all sufficient. For example, a sophisticated mail system configuration might have configs for different virtual domains. The configuration items for each virtual domain should have names which include the domain. Therefore, in principle, the names of config items might not be known until bits of script belonging to the package have been run. Perhaps we want to separate out these `parameters' to config item names ? Then you could have a file which contained query strings something like this: mail-transfer-agent.virtualdomain.aliasfile.%domain "The file which lists aliases for the virtual domain %domain. Each line `<alias>: <newaddress>' in it will arrange for mail to <alias>@%domain to be forwarded to <newaddress>." In any case, in order to get backward compatibility with old versions of dpkg, the postinst script will have to be able to invoke the config manager programs to do actual queries in case dpkg didn't know how to set up the data wherever it is. III. What form does the specification of which questions to ask take ? There will clearly have to be a file or files that tell dpkg or the config manager what questions to ask. These file(s) must be useable when separated out of the .deb, so that we can do prompt-before-install. It is my belief that at least _which_ questions are asked can only be determined programatically, even if there is in some sense a set of possible questions which could be listed. The obvious thing to do is to have a script which dpkg invokes which just asks the questions and stores the answers. It would use some kind of tool which would ask the question and store the answer all in one go. However, this suffers from the problem that this script has to implement the `back' button, etc. So, I propose the following: the script asks all the questions for the package in order, but can exit with a special exit status meaning `please reinvoke me because the user pressed the back button'. When the user presses back, the query tool sets a flag in the _previous_ question asked (which has to be logged) and returns this exit status so that the script (which is using set -e) does too. Then the script goes through the questions again finding the previous answers in the cache until it gets to the flagged one. For simple packages we should provide a way to put all the questions in a file and have the query tool iterate itself. For compatibility with older versions of dpkg which don't know to invoke the new config maintainer script, or installation methods which don't have the scripts available all at once at the start, we should have the postinst call the config manager to run the config script just like dpkg does, so that it doesn't need to care about info not being available and can just retrieve it. IV. What `types' of the configuration data are there ? Is its type stored in the database of answers ? It's entirely unclear to me that anything except the user prompting part of the configuration management system (which has to be invoked with the names of the data entries et al available) needs to know the types of these entries. Carrying type around with the data also produces problems when different parts of the system (data from different sources, different packages using the same data item, old and new versions of packages and config manager) disagree with the nominal type, and means we need to invent a type naming system with all the usual backward compability features. Instead, I think that data should be transported as opaque strings and validated at the point of use. The facility that retrieves a data item should be told the expected `type' and check that the string matches it (by regexp, or whatever). V. Where to put the configuration prompting in the .deb ? I think it is important to make new packages install on old versions of dpkg. Remember, no non-backward-compatible changes without a phase-in period, during which new+new code works in the new way but new+old or old+new works in the old. We also don't want to increase the size of the .deb more than we can help, and preserve its current reasonably clean structure and be as backward compatible as possible Current suggestions seem to be to put the information in additional members of the enclosing ar archive. I disagree with this; I think we should put it in the control.tar.gz subarchive. Unpacking this part is necessary even to find out the name of the package, for crying out loud. There's no harm in requiring its unpacking for pre-configuration. This will also have the benefit that current dpkg versions will ignore it. VI. How does the config manager talk to the package ? I think there are pretty much only two sensible answers to this question: (a) program call or (b) C library call. These calls will allow the package to ask for information and give details about defaults, and should automatically use whatever UI is currently in place. If there is to be a protocol between different parts of the system it should be internal. Ian.
