Re: policy changes toward Non-Interactive installation
Manoj Srivastava wrote:
> I do apologize. I was not talkgin about debconf, since I am
> not very knowledgeable about it (I have not been keeping up with it,
> unfortunately). I do intend a flag day soon to convert all my
> packages over.
No problem.
> Given my ignorance of things debconf, could you please
> elucidate a few points?
Sure.
> >> How about this scenario: Package A needs to run a program from
> >> Package B, and let the user choose between alternatives in order to
> >> configure package A to be in a working state. Unfortunately, the
> >> alternatives are not known before the program is run. Package A is a
> >> daemon process, so we stop the daemon before unpacking, and we start
> >> it after configuring. We pre-depend on package B, so that our program
> >> is available to us.
>
> Joey> Yes, debconf can handle this, with no behavior changes *at all*
> Joey> from how it would have traditionally been done.
>
> This is interesting. Since we do not know what the options
> are, or even whether to ask the question, before unpacking, how do
> you handle this?
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.
> 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.
(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.
--
see shy jo
Reply to: