Re: Proposal: Automatic query servicing for dpkg installation scripts
Ian Jackson wrote:
>Yes, we do need something like this.
>
>Properties that it needs to have include (and not all of these are
>true of your proposal), in no particular order:
>
>1. Questions may need to be `independent' of any particular package.
>
>2. Only a particular package can determine which questions need to be
>asked in what order; in particular, following questions can depend on
>the previous ones. This means that we can't specify the questions in
>advance in a file. Instead, we have to put the information in
>command-line arguments to the query program.
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.
If the questions are out in the database, they can much more easily be
internationalised; is this a goal of the project?
>
>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.
>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?
I think I need some meaningful names attached to the different levels
of prompting so that I can understand how you are thinking.
>5. The interface should be suitable for changing the UI later (eg,
>plain-text, fullscreen text, X or whatever).
>
>6. The database format used to cache answers should be editable by
>humans.
>
>7. The query program should be the same as the retrieve-question
>program, so that the database of previous questions acts as a cache
>for the user.
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.
>
>8. If the query program cannot prompt but the arguments say it needs
>to then it should indicate this with a nonzero exit status, which will
>(hopefully) cause the script to bomb out.
>
>9. Valid responses should be specified by regexp (preferably a
>reasonably fully-featured regexp like a Perl one) not a glob.
It would probably be better to write in Perl than shell script; then it
would be easier to achieve this.
>
>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?
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"But as it is written, Eye hath not seen, nor ear
heard, neither have entered into the heart of man, the
things which God hath prepared for them that love
him." I Corinthians 2:9
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: