Re: dpkg modification: non-interactivity
Jesus M. Gonzalez replies:
> 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).
Yes, this was the first point of view in Mitch's overview.
> 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 agree, at least it is not sufficient (I did think about it).
> 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.
A conservative way of doing this would be to simply change dpkg as follows:
If a file under /usr/share already exists and is identical to what dpkg
would put there then dpkg should quietly not touch it!
This would make it possible to share /usr/share, at least.
It is harder to do in general. Take, for example, byte-compiled Emacs lisp
files that are generated during postinst...but then again, it is possible
in the longer run.
> The rest of your proposal (postinst-interactive, "cookies",
> etc.), matchs well this situation. In fact, it could probably be
> autoamted with cfengine, for instance.
Yes but I *do* prefer a conservative extension using just base debian
tools, at least to start with.
> 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...
This is what the "mirror .deb" should do: it does not have to contain *all*
packages of the master machine, just those that should be systematically
installed.
In the long run I agree that some cfengine-based approach should be used,
if just to run "dpkg --install" of the mirror package whenever it
appears...
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 <Kristoffer.Rose@ENS-Lyon.FR>
pgp f-p: A4D3 5BD7 3EC5 7CA2 924E D21D 126B B8E0 <krisrose@{debian,tug}.org>
Reply to: