Sorry for quoting out of order, but.. On Mon, Jul 27, 1998 at 07:27:38PM -0400, Raul Miller wrote: > Or do we want to talk about creating a query system where the package > pre-registers its queries with dpkg, and dpkg is allowed to obtain the > answers to these questions before the package is unpacked? In some ways, > this would be a cleaner system, but I'm not sure if it would work for > packages with complex requirements. > > Remember that some packages just run a program under /usr/sbin/ for > their prompting, and remember that apt will run dpkg multiple times, > and remember that some packages are currently introspecting to decide > whether or not the user should be prompted.
From where I sit, it either needs to ask all of the questions at the
beginning before download/unpack or after everything is downloaded and
unpacked if possible.
Seems like the thing to do is agree to and adjust policy such that preinst
does not interrupt the process (ie, no prompts) and modify dpkg to support
--unpack-only or similar.. Then apt just needs to sort out predepends.
Predepends are the only time when you'd need to finish postinst BEFORE you
could unpack other programs..
In the case of predepends, I have no idea what to do. But if all the
postinst that could be was saved till after everything else was done, you
just come back to the machine and answer remaining questions...
> We're talking about a user-interface mechanism, and we haven't defined
> an event-driven environment for dpkg installation and removal scripts
> to exist in, so it's not quite that simple.
It's been mentioned that we need a way to have configuration program/script
things be able to talk to other front-end things... I have a very simple
solution to this. a dwww like perl front end could do this as well as a
slang front end or a gtk one.. A possible beginning of an implementation
might be:
Script commands:
TITLE "Title text here"
HEADING "This at the top of a section"
MENU label "description"
STATIC "Plain text that does nothing really"
BOOLEAN label "description" optional_default
NUMERIC label "description" optional_default
PULLDOWN label "description"
RADIO label "optional description"
ITEM "description"
DEFAULT number
STRING label "description" "optional default"
ERROR/ENDERROR
READY
others?
TITLE sets the main screen title.. The page title in HTML or the
background title in dialog and the like, you get the idea. HEADING is just
a way to have things with seperate blocks of configuration be able to have
seperate blocks.. This is the <H2>..</H2> type thing. STATUC is just
normal text. It's meant to be info on how to set things and the like.
BOOLEAN, NUMERIC, and STRING are just ways to ask for values.. In HTML
there's no way to check for numeric or string, so such a front end would
have to test this itself and act as if it got an ERROR (see below..)
PULLDOWN and RADIO work the same way, other than how they are displayed.
RADIO might be displayed as
Optional description
(*) Option1
( ) Option2
:
while pulldown would be more like
Description [Option1 ]
Both take ITEM commands, which is the only place ITEM means anything.
Anything other than ITEM is ignored for a pulldown, but if people don't
think it would be hard, NUMERIC and STRING should work.. The reason:
( ) Other: __________________
The number of ITEM (or whatever) commands is counted.. When the front-end
SET's (see below) a PULLDOWN or RADIO, it sets it to the number of the
choice selected. It's not up to the front-end to make sure the back-end
script or whatever knows that for the last option in the RADIO it needs to
use the value in label...
DEFAULT is used to end a PULLDOWN or RADIO.
MENU indicates a hyperlink type thing. This part has not been well-thought
yet. I thought it was, but it's not really after thinking about it. The
idea was that there could be something like update-config that would
register a config method and when you start a front-end without a package
name to configure it could use the above commands to create a list of
packages---maybe sorted somehow even ... Those would just be MENU package
"registered description" commands.. When the config menu had something
selected, it'd just run the thing.. I'm not sure how to handle that though
ERROR is sent after you submit SETs and the like.. If the value given the
script is bad, it replies with ERROR, describes the problem, then does an
ENDERROR followed by the things it needs fixed. Between ERROR and ENDERROR
is a lot like STATIC.. It's lile the HTML <PRE> tag I guess..
After it's sent all it wants on a page it sends READY which means it's done
and the program can send any chnages the user makes and saves whenever it
wants.
Front-end commands:
MENU label
SET label whatever
READY
others?
The front end talks back to the script, but the things it says are more
simple. When a MENU above is selected, the MENU label command is echoed
back followed by a READY...
SET's can also be done.. SET is universal, it can be used to set anything,
be it string, numeric, whatever.. If the back-end gets something it doesn't
like, that's what ERROR is for, see above.
Anything else the front-end may want to send the back-ends? No idea. This
is just an outline of how it could be done. Opinions wanted. =>
pgpHkwWFy2lCr.pgp
Description: PGP signature
