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

Re: policy changes toward Non-Interactive installation

Joey Hess <joeyh@debian.org> writes:

> Manoj Srivastava wrote:
> Quite simply: This type of thing can not be handled before unpacking, so
> it isn't. Debconf allows package to ask questions in their postinst,
> this is just *strongly* discouraged. See the realplayer installer for a
> package that (rarely) has to use debconf interactively in its postinst.

My option on this that packages that need to ask questions after
unpacking should not be setup toether with packages that don't need

There should be a preconfigure and postconfigure and the unpacking
inbetween those should be non-interactive. There is no need to stop
all packages from being configured just because the kernel-image
packages needs some input. Downtime of services should be minimal.
> > 	Let me try a concrete example; the kernel image postinst, and
> >  see how far we get. These are the questions the kernel image
> >  postinstall asks, and I have tried to figure out if the question can
> >  be pre asked. 
> > 
> > ======================================================================
> >  ------------- Question depends on test on fie system
> > / ------------ Question important (IMHO)
> > |/ ----------- Depends on previous answer         
> > ||/ ---------- Needs run time test
> > |||/         __ can be pre asked
> > ||||        /
> > ||||        |
> > ||||        |   
> > X...........Y    1) Ask to remove /System.map files
> > .X          Y    2) ask to prepare a boot floppy
> > XXX.........Y    3) ask which floppy drive to use
> > .XX.........?    4) do I need to format the floppy?
> > .XXX........N    5) Insert floppy, hit return
> > .XXX........N    6) failure, retry?
> > .XXX........N    7) failure, you have formatted floppy?
> > .XXX........N    8) you have floppy, hit return when ready
> > .XXX........N    9) Failure writing floppy, retry?
> > .XXX........N   10) failure, hit return when youhave new floppy
> > XX..........Y   11) if conf exists ask if we should run $loader with old config
> > XXX.........Y   12)                Or else ask if a new $loader config
> > .XX.........Y   13) Or else ask if loader needed at all
> > .XX.........N   14) Install boot vlock on partition detected at runtime
> > XXXX........N   15) Install mbr root disk
> > .XXX........N   16) Failure writing mbr, do this manually, hit return 
> > .XX.........N   17) make that partition active?
> > ======================================================================
> Right. This is obviously a rather important package, which *cannot*
> fail, plus is is very dependant on the actual state of the system. As
> such, the best you'll be able to do is allow a few questions to be
> pre-asked, and defer the remainder to the appropriate maintainer script.

I think that the configuring the package twice is not so good. If you
know that you need to bother the user after unpacking anyway, lets do
it all in one step.
> (BTW, I'm ccing this to Wichert and AJ as a sterling example of why
> debconf has to continue to support this type of thing in maintainer
> scripts. I think both of them don't want it to have this capability, but
> it is, as you have noted, essential for some packages.

May the Source be with you.

Reply to: