Previously Ian Jackson wrote: > 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). I don't they we really jumped past them, although some might not have received quite enough thought. > 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: Aren't both sort of the same? If you load things earlier you get defaults, making requesting things a trvial case of a more general scheme. > (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. Which would mean explicitely reloading the cache, which makes it a something else.. > 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. I don't follow that. What do you mean with `explicitly 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. Which means we still have to write the code to handle different databases etc., you only relocated it.. > (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. That's a good point. > (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. But (a) already suffers from that: first you say we should use it as a cache, and now you want to write to it? If not, you have the same asymmetry for (a) and (b), except that (b) gives you an option to remove the assymetry by allowing you to specify a symmetric setup. > (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' ? > Therefore, in principle, the names of config items might not be known > until bits of script belonging to the package have been run. You're right about that. > 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: I really like that idea. /me kicks himself for not thinking of that. Basically it means you want more control over the variables-list: being able to add and remove variables on demand. > 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. Which would also mean you need to depend on the config-manager, which seems ugly. Then again, all packages also depend on libc6 > 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. I think we alread said that explicitly somewhere. If not it was done implicitely :) > 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. I since a contradiction here: first you let the script run a tool to ask the questions, and the you let the tool restart the postinst to implement a back option? Also adding more meta-data just to implement a back-button seems not right to me, I feels like a hack-approach. > For simple packages we should provide a way to put all the questions > in a file and have the query tool iterate itself. `if dpkg supports configmodules and no configmodule is supplied, ask all supplied variables. Otherwise do that from a (post|pre)inst' > 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. But since you yourself said above there should be a way to ask questions without needing a configmodule for simple packages you need to store the type.. > 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). So you don't check it on storate but also on every retrieval? Isn't that doing way too much work? > 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. Yes sir! > 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. Even more important: it will mean it will get stored in /var/lib/dpkg/info (or wherever that will move in the future). > 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. (b) is not really possibly since we are dealing with scripts. And (a) is is complicated in that it makes it more difficult to gather a group of questions flexibly. Wichert. (who's really going to sleep now) -- ============================================================================== This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: wakkerma@wi.LeidenUniv.nl WWW: http://www.wi.leidenuniv.nl/~wichert/
Attachment:
pgpscVsBYQUBB.pgp
Description: PGP signature