Re: Proposal: Automatic query servicing for dpkg installation scripts
Oliver Elphick writes ("Re: Proposal: Automatic query servicing for dpkg installation scripts "):
...
> Are there any scripts that actually build their questions? Isn't it
> usually (always?) the case that the question is in the script as a text
> string, though the logic may skip it? Where parameters are needed,
> I should like to be able to pass them in, so that the question
> database would have to contain something like a printf format string.
Yes. For example, the scripts in the base setup procedure that ask
for your IP address et al. (`What is the address of system iguana'.)
You might have a fancy nameserver configuration which would prompt for
zones to primary and secondary, or something.
> If the questions are out in the database, they can much more easily be
> internationalised; is this a goal of the project?
Certainly it is a goal. However, I think we should distinguish
question strings (which are essentially static) from question
name,answer pairs.
> >3. Questions should have a `name' that is textual (not numeric), and
> >is separate from the prompt string. Given 1. the name should probably
> >have a hierarchical structure. Given 2. there needs to be a way to
> >put arbitrary `parameters' into the `name'.
>
> The way I wrote the script, it could have any arbitrary text, except for
> the delimiter character; I thought of it as a number, because that means
> less typing.
We need more structure for this, so just numbers are not appropriate.
Obviously the documentation should define the syntax for question
names, and the implementation should enforce it.
> >4. There should be a way to specify how `important' it is that a
> >question be asked, and an environment variable or something to specify
> >how willing we are to prompt, so that we can tune the level of
> >prompting.
>
> Presumably this is when there is no default in the database?
> Is this to enable the installation scripts to ask only `important'
> questions, whereas a different context would prompt more readily?
Yes.
> I think I need some meaningful names attached to the different levels
> of prompting so that I can understand how you are thinking.
Welcome to your new Debian GNU/Linux installation.
You may choose now in a very broad way how much you want to be asked
about the installation and configuration process. If after the
installation you want to configure programs in more detail, please
run the `dconfig' utility.
[E] Express setup. Only the most vital questions are asked.
[C] Custom setup. Any reasonably-relevant question will be asked.
[D] Detailed configuration. Only experts will understand many of
the questions.
[N] Absolutely no prompting. Not recommended; some programs will
not be correctly configured.
[L] Load configuration data from another system.
If you are asked a question you do not understand, choose the
default option if there is one. This will always be reasonable.
> My script was using different calling names to distinguish its function;
> I think I can do better by duplicating file pointers, but I haven't
> really thought how yet. I need to distinguish output of the question to
> the screen from output of the answer to the calling script.
A program like this can legitimately access /dev/tty (or DISPLAY or
whatever). At some point dpkg scripts' stdin will be connected to
/dev/null and its stdout and stderr directed into a logfile.
...
> >10. Metacharacters in prompts and data should work completely
> >correctly.
>
> Again, this is more difficult to achieve in shellscript; however, what
> should metacharacters be doing in this context? Correctness implies a
> specification to measure against. Are we talking about shell or
> regexp metacharacters here?
I mean that there should be no characters which cannot be handled both
as parts of query strings or in data items. So, the database format
and mechanisms for getting data in and out need an escaping mechanism.
Ian.
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: