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
