Re: dpkg modification: non-interactivity
From my point of view, your proposal also addresses an
interesting problem in standalone installations. That problem is the
continuous need of user atention during the configuration
phase. Although most packages don't need any interaction, some human
has to be around just to answer questions when some package needs that
interaction. The result is that you have to wait looking at the screen
during all the configuration phase. With your proposal, that can be
shortened to the "postinst-interactive" phase (only for the packages
that need it).
On another topic, I'm also worried by the instalation of
machines sharing disks (via NFS or CODA). In that cases, you can share
a single /usr, for instance, for many machines. Your approach doesn't
work in taht case, since on the "clients", you cannot install
packages, since you cannot overwrite /usr (and you shouldn't, anyway).
I have a proposal to also address this setup:
Have a way to specify to dpkg which directories are from an
"already installed server". In that case, instead of installing files
in that directories, dpkg will just check that that files are already
there. A simple case is let dpkg just "do nothing" for that files,
assuming they are correctly installed.
The rest of your proposal (postinst-interactive, "cookies",
etc.), matchs well this situation. In fact, it could probably be
autoamted with cfengine, for instance.
However, you should have a way to specify which packages are
to be installed in which machines in an "automated" way. For instance,
probably you only want apache in your WWW machine (or at least, you
only want to have it configured there). Therefore, you'll need some
way of "marking" which packages are to be installed on
clients. Usually, that's not just a "mirror" of the server...
Jesus.
Kristoffer.Rose@ENS-Lyon.FR writes:
> Mitch writes:
> > This confuses me. And I think others may also be getting confused because
> > we have suggestions coming from two different use cases.
>
> Indeed: I was trying to address both even if it wasn't very clear :)
>
> Here is the essence of my PROPOSAL again:
>
> a. Policy is changed to FORBID INTERACTION during postinst.
> b. Policy adds a SECOND SCRIPT PHASE -- call it postinst-interactive --
> where one *is* permitted to do interaction.
> c. Policy requires that postinst-interactive leaves a COOKIE behind that
> makes subsequent runs of it non-interactive for the same version.
>
> [...]
--
Jesus M. Gonzalez Barahona | Departamento de Informatica
tel +3491 624 9458, fax +3491 624 9129 | Universidad Carlos III de Madrid
jgb@gsyc.inf.uc3m.es, jgb@computer.org | avd. Universidad, 30
Grupo de Sistemas y Comunicaciones | 28911 Leganes, Spain
Reply to: