[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: