Re: More thoughts on dpkg prompting
Some ideas form an implementation :
- questions should have some class model.
for example one class could be "Select your default %s",
this will be implemented as "xserver", "dictionary", "windowmanager" ...
- smart trigger model. installing a windowmanager should trigger
"Select your default %s" : "windowmanager". With smart i mean :
if i'm upgradeing and not installing, there is no need to ask me.
- "not yet" mechanism : it should be possible to skip every question,
for example if you want to read the docs first.
- todo list mechanism : if a questzion was skiped, this should be logged in
a todo list, so later you can work off these things.
- configurable defaults. the mechanism would be by default interactive,
but could also changed in both directions ( verbose (newbies or so) :
ask everytime, even when updateing to a new version, quiet (admins) :
use the "don't hurt" defaults, and register for todo list).
- interaction and executive should be two seperate programs.
this way the executive stuff can be also used by scripts (if you have many
machines, you will love to use scripts to manage them).
> 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/.]
oh, i see, we agree. but wouldn't /etc be a better place, since it's config
data ? you need that stuff, when restoreing a system or building a clone ...
> 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.
hmm. what about "Select your default %s" : "configuration programm" -> basic /
menu / x11 menu / ... ?
i don't like to use the path to select what software in run.
>(*) There should be a way of distinguishing between dpkg status messages,
>{pre,post}{inst,rm} status messages, and prompts.
i think there is no point in messages in post/pre rm/inst scripts, unless they
halt. most people don't read them, because they went for a cup of tea or so.
Maybe we can have some "Informal Message from %s :\n%s" class, and use the
same mechanism to select whether to wait for input or register in TODO list ?
>(*) 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).
i suggest one or two central persons, who keep a list up to date,
and give suggestions how a key could be named. many things can work as a
combination of class, type and package name, e.g.
pickone/windowmanager/fvwm2 (or "." or ...).
>(*) 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.
we can improve many questions. for example the windowmanager packages contain
"make this your default wm yesy/no". it would be nice, if the new dialog shows
a list of all windowmanager, marsk the new one as "(new)" and lets you pick
the default one.
one more idea for implementation : it would be nice, if some questions
could be marked as "process at end of installation". yes, this requires the
install tool to invoke the tool at the end of installation. the benefits are :
- call update-menus only once
- call the "select your default wm" only once, with a list of all new
windowmanager.
>(*) It's really not reasonable to lock down the design until we have
>several input mechanisms fleshed out.
i agree. lets write one version, and if it has flaws, then rewrite the whole
thing useing the new know-how.
>(*) We must have human-edittable files representing the data.
absolutely. everyone likes text files, so we can use grep, sed, ...
>(*) 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).
oh, don't forget a way to override things for the admin. i still don't know
how to change the alternatives tuff, so it will keep longer than one update
sequence.
>(*) 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.
we should be able to keep keys in the database after something is removed
(add a "#" to the beginning ?).
i would also like to have some higher level mechanisms, e.g. for the mime
stuff. if i could say "use xv where possible", would eleminate many questions.
hmm. since this isn't the first time this is discussed :
is anyone codeing ?
andreas
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: