More thoughts on dpkg prompting

[Raul Miller <rdm@test.legislate.com>]

I've been thinking a bit more about implementation issues for dealing
with too many prompts during installation.

(*) we still need to emphasize the need for reasonable defaults,
introducing this configuration mechanism doesn't solve problems, it just
gives another way of dealing with problems.

(*) There's probably no need for two distinct flags on key/value pairs.
The "readonly" flag is better expressed as an environmental variable
(constant for the whole run of dpkg) than a property of some key/value
pair.  There's other flags too, which could be stuffed in environmental
variables (never prompt comes to mind).  I'm thinking that if the system
is not in read-only mode it will remember the admin's response so that
it's the default next time around.

(*) we need to think a bit about implementation: we need to solve some
of the same problems that are solved in an object-oriented language,
but we need to solve it in a command-line scripting environment
(without restricting the choice of scripting language).  I think that
this means a two-layer mechanism: at the bottom is the interfaces
for accessing the data [none of the code above this level knows about
/var/lib/dpkg/querydb/.]  Above that is a set of programs to do prompting.
The initial set of programs just print to stdout and read from stdin,
and they're in some special directory that dpkg sticks onto the end
of its path.  Fancier programs (X aware, for example) work by having
something else already in the path that provides some or all programs.
[And the fancier program should be prepared to do something reasonable
with stdin and stdout.]

(*) There should be a way of distinguishing between dpkg status messages,
{pre,post}{inst,rm} status messages, and prompts.

(*) If we do this, package maintainers will be obligated to keep a file
documenting all historic use of keys (so that we don't have bugs from
upgrading an old package that used the key in a different way).

(*) There are a variety of standard prompts that will be needed, but
I'm having trouble ennumerating them.  Ones that are obvious to me are
simple yes/no or yes/no/quit style prompts, and "have you seen this
message" style prompts (saves the message and doesn't ask for return to
be hit next time around if that exact message was seen the last time),
but fancier prompts I'm a bit more dubious about.  Can we get by with
just a "type in your response" for fancier cases?  I don't know.

(*) It's really not reasonable to lock down the design until we have
several input mechanisms fleshed out.

(*) We must have human-edittable files representing the data.

(*) While we're dealing with user-interface implementation, we ought to
put in some of the basics (like being able to bring up help describing
in more detail what is being looked for).

(*) I'm thinking that for the basic (tty) mechanism, a ? by itself would
represent a request for help, and a trailing ! after some significant
response would make that value remain the next time around.

(*) I'm thinking that the mime-ordering mechanism would not fit into this
scheme at all, and it shouldn't either: it would be better to introduce
some kind of priority registry (kind of like update-alternatives).
For compatibility with hand-editted files, if there's no obvious priority
on the entry then that entry takes precedence over anything with an
automatically set priority.

(*) It would be incredibly easy to try to overdesign this thing, but
simplicity is important too.  I don't think we need to be excessive about
tracking key/value pairs across upgrades.  So we need a way of marking
a key/value pair as obsolete (it wasn't used last time the package was
configured), and we need a way of tossing obsolete key/value pairs,
and we shouldn't be too worried about package design changes that change
the prompt structure.

-- 
Raul

> Martin Schulze <joey@kuolema.Infodrom.North.DE> wrote:
> > Database, this reminds me. The *SQL packages ought to ask in their
> > postrm script if the database data shall be remove, too. I'd like to
> > see the same (I'd prefer a non-asking mechanism) would happen to not
> > maintained (i.e. no rotating script, no package) logfiles.
> 
> Speaking of which, has anyone come up with a design for a prompting
> system for dpkg, which let's you prompt only when desired?
> 
> We've got five major needs:
> 
> (1) dpkg {pre,post}{inst,rm} scripts need to glean information about
> what the system administrator (user) wants.
> 
> (2) it should be simple and direct for first-timers
> 
> (3) it should scale easily for people doing batch installs
> 
> (4) prompting should be kept to a minimum
> 
> (5) system integrity is sacred
> 
> ----------------------------------------------------------------------
> 
> I'm thinking we want an enhanced key/value system.  The key should 
> be derived from the package name.  The value should be enhanced with
> some set of flags.  There should be a way of falling back to values
> associated with some other keys (for example, when package names
> change for whatever reason).  
> 
> I can think of two flags that are reasonable:
> 
> (*) Use this value (if not set, this value is just a default).
> (*) Value is read-only (if not set, we record the value the user enters).
> 
> I don't think it's right to require the system to do prompting, but
> we probably want to provide some basic utilities to do common kinds 
> of prompting.
> 
> I'm thinking that a directory under /var/lib/dpkg/ is as good a place
> as any for this stuff to go -- one file per package with queries.
> We'd want to make it easy to symlink it elsewhere, for people doing
> network installs -- but I think that can be addressed just by documenting
> the mechanism and having network install people make their own base
> disk (or base image for use in nfs install, or whatever).
> 
> We want a certain amount of flexibility in the data we handle.  But
> before delving into file format I wonder if anyone has any objections?


--  
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org