[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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
  >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
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: