Re: Configuration management
Ian Jackson wrote:
> 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.
Couldn't this be represented as an array or hash of data bound to a single
question? (ie, mail-transfer-agent.virtualdomain.aliasfile{domain})
> 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.
Agreed.
I would still like to keep the list of possible questions if that is doable.
It adds a lot of flexability to what the frontend can do, and it lets you
construct a database where you know you have answered every possible
question, wich allows unattended installs that really work. If the scripts
can come up with entirely new questions on the fly, this isn't possible.
> 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.
This feels like a kludge. If the script has a significant startup time for
some reason we don't want to reinvoke it for every hit of a back button.
I don't see any reason why the scripts cannot contain all this flow control
in itself. It's very easy to do if you allow GOTO, and it's reasonably easy to
do cleanly.
Your idea is fine as the default, just so long as the script can optionally
catch that return code and handle flow control on its own.
> 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.
This is good. Another use of this is that we will be able to replace the
current programs like slrnconfig, smailconfig, etc, with similar programs
thatuse the config manager. If they are run standalone, they run the config
manager, if run from the postinst, the config manager will already be running.
> 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).
This doesn't let us have things like arrays. I agree that we don't need a
strongly typed system, but we do need support for at least an array data
type. Some uses:
* the email virtual domain example above
* the list of window managers
* the list of directories for /etc/ld.so.conf
--
see shy jo
Reply to: