On Tue, 18 Aug 1998, Ian Jackson wrote: > I. How is amalgamation of data from various sources done ?
We can probably regulate this to a more implementation issue. So long as when the package requests something it is retrieved from -someplace- exactly how is quite flexable. > 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. Hm, the simple solution is something more like a template, I've already argued why script-only configuration is not so usefull ... An example Variable: mail/virtualdomains/*/domain Description: The full domain name for the virtual host. The * would be a match anything sort of arrangement, so that mail/virtualdomains/debian.org/domain mail/virtualdomains/bugs.debian.org/domain Have the same meta-data. This allows the creation of 'arrays of structures' inside the database. > mail-transfer-agent.virtualdomain.aliasfile.%domain This is also quite possible, in the notation we have been using, Variable: mail/virtualdomains/domain/* I think the other system is more usefull to the user beacuse a subtree query command will show the entire configuration ie: $ config-query show mail/virtualdomains/debian.org Domain debian.org AliasFile /etc/aliases Foo Bar ... Similary for a browsing GUI the experience to the user is much more sensible. > 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. Personally I don't see any need to modify dpkg. We need to have a script that can generate the default configuration file. It is amazingly similar to our current postinst's except instead of using a shell construct to query the user it uses a shell construct to invoke the query program. How would you propose that dpkg get involved? > III. What form does the specification of which questions to ask take ? > 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. Yes of course, but you have to envision what sort of GUI's we wish to present. I outlined my ideas for a dual mode gui that is capable of both directly editing the database and running 'wizard-like' scripts to guide the novice. The original ideas were basically a series of 'wizard-like' scripts strung together. I've said before that I don't think this solution gives the appropriate fineness or sufficient user-friendlyness. For simple packages I (the user) probably do NOT CARE what they configure themselves to be. I have no interest in mime-type configuration, no desire to do things with my mailer or apache. I just want them to work and I don't want to be bothered because I have nothing to tell them. 99% of all packages should require very, VERY minimal configuration but on the flip side packages should be highly configurable and have lots of questions! The goals conflict :> > 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. My view is that the type is used by the GUI to guide the user and optionally [depending on the script] by the query program to protect the script from invalid input. The database is, like you say, not type enforced. > 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). It would make sense to retrive this from the variables definition so we don't duplicate information. > 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. Agreed. I'd like to see some of the information avilable sperate on the FTP howerver. Jason
