[EMAIL PROTECTED] wrote: > a. Policy is changed to FORBID INTERACTION during postinst.
You could check a shell variable if interaction is forbidden, ... > b. Policy adds a SECOND SCRIPT PHASE -- call it postinst-interactive -- > where one *is* permitted to do interaction. ... which makes this one unnecessary. > c. Policy requires that postinst-interactive leaves a COOKIE behind that > makes subsequent runs of it non-interactive for the same version. 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. 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. > I assume that this is implemented in dpkg (hey, I might even help because > these are *really* easy :). It's even simpler the above way as it does not require any changes to dpkg at all. Just my 0.02 Euro. -- Stefan Gybas