Still working on the twiki package. The postinst uses sh, and does a . /usr/share/debconf/confmodule at the top, so it get db_get a few things and set up config files appropriately. Then it does db_stop so that I can do some apache-related reconfiguration. Since my package requires a new apache module to be enabled (mod_actions, part of the core but often not enabled) it has to do the DSO scan again: /usr/sbin/apacheconfig --force-modules However, this prompts the user Y/n about updating the apache config files. since db_stop doesn't actually get rid of the frontend, file descriptor 0 is still frontend, and so the read sits there and nothing happens... I *think* I can move enough of the work up above the confmodule startup, since it doesn't look like it strictly depends on the answers to the debconf questions. It is tricky enough that I'd rather not, if I can avoid it; and suppose it isn't the case, there should be some way around this. (The debconf docs seem to indicate that db_stop should suffice; suggestions for other ways of handling this are welcome...)
package debconf merge 142944 194152 tags 142944 + patch thanks Here is a tested patch to fix the long-standing bug in debconf where it doesn't restore stdin. It also closes the extranious fd 3 when it is no longer needed. Note that this is less work than a reasonably correct and mostly working fix for the bug in a single package that uses both debconf and ucf. Your claims that is bug is documended in debconf-devel(7) are false. There is no workaround there either.--- confmodule.save 2004-01-05 19:52:20.000000000 -0800 +++ confmodule 2004-01-07 19:53:39.000000000 -0800 @@ -7,6 +7,12 @@ # Check to see if a FrontEnd is running. if [ ! "$DEBIAN_HAS_FRONTEND" ]; then + if [ ! "$DEBCONF_SAVED_STDIN" ] ; then + # save stdin + exec 4<&0 + DEBCONF_SAVED_STDIN=1 + export DEBCONF_SAVED_STDIN + fi # Ok, this is pretty crazy. Since there is no FrontEnd, this # program execs a FrontEnd. It will then run a new copy of $0 that # can talk to it. @@ -67,4 +73,11 @@ # Cannot read a return code, since there is none and we would block. db_stop () { echo STOP >&3 + exec 3>&- + if [ "$DEBCONF_SAVED_STDIN" ] ; then + exec 0<&4 4<&- + else + # needed by dpkg-reconfigure + exec 0</dev/tty + fi }
Blars Blarson wrote: This will likely cause every postinst that uses debconf, starts a daemon, does not call STOP, and only works around closing cd 3 to hang.
Of the 78 packages I found that use debconf, don't do db_stop, and use one of start-stop-daemon, invoke-rc.d, and /etc/init.d/ , I don't see anything that works around your leaving fd 3 open. Some daemons will close extranious file descriptors they are passed, but that should handle fd 4 as well. Why would having an extra file-descriptor open for reading (probably from /dev/tty or /dev/null) cause the postinst to hang?
Such debian-modified daemons are buggy. They should not be closing just fd 3, but be doing it correctly.
There will be a number of daemons that will only close file descriptors 0, 1 and 2 (I know at least one of my packages does this). Using db_stop before starting the daemon handles the Debconf control fd.
Andreas Metzler wrote: Right, I'm fairly sure that at least a few daemons have been modified for debian, perhaps changed to close only fd 3, and would trip over this sort of change. I regard this as an api change for a library, and if I accept it I will probably do so by changing the library's "soname" -- which in this case means adding a new version of /usr/share/debconf/confmodule under a new name. I have not decided if I will accept this change, since it conflicts with how debconf is intended to be used on a philosphical level. Do I really want to make it easier for postinst scripts to bypass debconf in prompting the user, an action which is now deprecated by policy?
On Sun, 11 Jan 2004 18:08:01 -0500, Joey Hess <joey@kitenet.net> said: Policy merely states that you must needs use a debconf like mechanism to talk to the user -- something that follows the policy spec. That does not imply that debconf has sole rights -- one could well have an alternate mechanism to talk to the user, which is policy compliant, and not debconf. Hence, stealing away stdin is a bug. manoj
Manoj Srivastava wrote: No, policy specifies that scripts should prompt by communicating with a program such as debconf which implements the Debian Configuration management specification. That specification, as I pointed out before, requires that said communication be done using stdio. Debconf does not "steal" anything. If you choose to use it, you communicate with it using stdio.
What if I chose to use two such frontends? There is nothing in policy that states that each script should communicate with one and only one debconf like program. In theoryu, I can ask a dozen questions, each using a different debconf like program -- and be policy compliant. How does the second, third and so forth program get hold of STDIN? manoj
Manoj Srivastava wrote: This is not something that I have the least little interest in trying to support, for a wide variety of reasons that I will not go into here.
I can understand that -- you have written debconf, and it probably perfectly satisfies your needs, and behaves in a fashion that feels absolutely natural and logical to you. but that does not mean that the current behaviour is one that would be optimal for other folks -- especially those considering writing another program that adheres to the debconf spec. manoj
Manoj Srivastava wrote: That has nothing to do with my reasons for feeling this is a bad idea. In fact I've done a fair bit of work on transitioning us to cdebconf (which I did not write) and expect to do more. Moreover, as with most software I write (or paintings I paint..), I can see problems in debconf that most people are not particularly aware of. My reasons have more to do with why we want to use a system like debconf in the first place, and how something like what you're describing could seriously undermine its advantages. Things like UI consitency, user control, a simple frontend-agnostic protocol, etc. As I said I'd prefer to not go into my reasons in depth here, so I'd appreciate it if you didn't attribute incorrect reasons to me.
Control: tags -1 - patch [..] Looks like the patch is not the patch people are looking for.