On Sat, Dec 19, 1998 at 12:30:45AM -0500, James LewisMoss wrote: > >>>>> On Tue, 15 Dec 1998 23:38:46 +0100 (CET), [EMAIL PROTECTED] 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... [EMAIL PROTECTED] [EMAIL PROTECTED] 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