Re: dpkg modification: non-interactivity
On Sat, Dec 19, 1998 at 12:30:45AM -0500, James LewisMoss wrote:
> >>>>> On Tue, 15 Dec 1998 23:38:46 +0100 (CET), Kristoffer.Rose@ENS-Lyon.FR said:
>
> Kristoffer> Stefan Gybas writes:
> >> > a. Policy is changed to FORBID INTERACTION during postinst.
> >>
> >> You could check a shell variable if interaction is forbidden, ...
>
No, dpkg *needs* to make two passes. a noninteractive pass and a run of the
interactive command queue.
This is to get rid of the "babysitting" phase of installation where
you have to sit around during the installation phase and wait to answer any
unimportant questions or hit enter for one of those annoying "hit enter to
continue" prompts.
There should be a variable that sets whether the interactive segment
of configuration is run directly after the noninteractive segment; no more.
> Kristoffer> Yes, or pass a parameter with "first" and "second" or
> Kristoffer> something. But the migration is then harder as *all*
> Kristoffer> scripts need to know about it before it works...
>
> >> This cookie can also be used in the standard postinst. So if you
> >> set this cookie before installing (e.g. by copying from a master
> >> server), no interaction is required at all.
Hmm. I must have missed this post, I just subscribed to this list a bit ago.
Anyway, here's what I think should be possible.
If the 'standards version' on a package is old (pre-non-interactive
stage) the package's postinst should automatically be considered
interactive; it will be configured after all the more recent ones. An old
standards-version should be considered a grave bug after this change.
otherwise the postinst should make a special call such as
"debian-register-interactive <package-name>-config.{sh,pl}" (yes, the name
should be standardized), where <package-name>-config is linked to /usr/sbin
(or /usr/X11R6/sbin) for future perusal, and registered as one of the
interactive config utilities to use.
Then, the next time dpkg --configure-interactive is run, everything
that has been registered in the interactive queue is run. Of course, the
non-interactive segment picks reasonable defaults, however broken that will
leave the package in a non-idea situation.
One of the other major strengths that this setup will offer is the
ability to run simultaneous jobs. IE you can be running 3 postinst scripts
at once, dramatically increasing speed.
>
> Kristoffer> Sure, this is ideal. Many postinst-scripts already do
> Kristoffer> this. Great, as I comment on in another message. But
> Kristoffer> the main point is that my idea is completely transparent
> Kristoffer> to the existing system: we file bugs, they get fixed, the
> Kristoffer> system gets better and better.
>
> >> postinst could also call a script "get-settings <packagename>"
> >> which could be customized by the admin to fetch the "cookies"
> >> (e.g. shell variables like CONFIG_SMAIL_SMARTHOST=mailserv and
> >> CONFIG_SAMBA_INETD=true) from a server, a local file or even
> >> generates them based on the installation host. Then if a variable
> >> is set, use that value, otherwise check if interaction is
> >> forbidden and use dafaults or ask questions.
>
Is this a discussion of network-wide settings? like, dpkg
--configure-interactive being run on one machine allows those settings to be
exported across a network for consistency? Gee, this is a really nice idea;
I'll have to check the list archives.
[snip]
Anyway, this looks really promising. All that is really needed IIRC is a few
people to actually work on something like this. Personally a lot of my time
is taken up hacking berlin....
--
..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org....
Berlin: http://www.berlin-consortium.org
Debian GNU/Linux: http://www.debian.org
----
Nullum magnum ingenium sine mixtura dementiae fuit.
[There is no great genius without some touch of madness.]
-- Seneca
Reply to: