Stefan Gybas writes:
> > a. Policy is changed to FORBID INTERACTION during postinst.
>
> You could check a shell variable if interaction is forbidden, ...
Yes, or pass a parameter with "first" and "second" or something. But the
migration is then harder as *all* 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.
Sure, this is ideal. Many postinst-scripts already do this. Great, as I
comment on in another message. But the main point is that my idea is
completely transparent to the existing system: we file bugs, they get
fixed, the 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.
Certainly. But too complicated to be *required* RSN.
> It's even simpler the above way as it does not require any changes
> to dpkg at all.
I think dpkg still needs to know that a package can be "half-configured",
if I understand you.
Cheers,
Kristoffer
--
Kristoffer Høgsbro Rose, phd, prof.associé <http://www.ens-lyon.fr/~krisrose>
addr. LIP, Ecole Normale Supérieure de Lyon, 46 Allée d'Italie, F-69364 Lyon 7
phone +33(0)4 7272 8642, fax +33(0)4 7272 8080 <[EMAIL PROTECTED]>
pgp f-p: A4D3 5BD7 3EC5 7CA2 924E D21D 126B B8E0 <[EMAIL PROTECTED],tug}.org>
