On Sun, Dec 25, 2005 at 01:51:00AM +0100, Sven Luther wrote: > On Sat, Dec 24, 2005 at 05:30:26PM +0000, Colin Watson wrote: > > On Sat, Dec 24, 2005 at 05:03:17PM +0100, Sven Luther wrote: > > > Notice that the debconf helper scripts provide stdout on &3, so any > > > scripts writing to stdout only need to redirect their output to &3, no > > > > My impression is that these days maintainer scripts are much better > > about not mixing up debconf interaction with normal use of stdout, and > > so it's still possible that the fd 3 hack will be removed some day. > > Ok, now i read it all, shouldn't really be replying to email after the > christmas party ... :)
Likewise, on Christmas Day I haven't really looked at this issue in any depth. :-) > So, do you have any idea of what is going wrong here and how to fix it ? I > mean having hosed powerpc kernels over christmas is really not the nicest > thing to have happen, and i really don't understand the subtleties of what is > going on here. > > k-p uses debconf (probably using the perl helpers you mentioned), and does a > db_stop before calling the script hooks. The STOP command causes the debconf frontend to shut down; that would certainly break anything trying to talk to debconf after it. May be worth removing that and seeing if things start working. I haven't checked if kernel-package runs anything else that would require it to use STOP. It seems a little unlikely that it would be starting up any daemons, though. Note a common misconception: the STOP command does *not* put your file descriptors back the way they were before you started the debconf frontend. > The script hooks, of which only mkvmlinuz uses debconf, but using debconf > being the right thing to do probably given the debconf-related policy, so the > script hooks calls debconf itself, which checks that debconf is not yet > running and reruns it if not. While it's correct for your hooks to load an appropriate debconf confmodule library (/usr/share/debconf/confmodule, in your case), the check you mention only works if the debconf frontend has never been started. It won't notice that you've shut the frontend down with STOP in the meantime. debconf isn't designed to be repeatedly shut down and started up again in the same process. > My belief is that somehow there is an inconsistency in the debconf helper, > maybe in the interaction of the perl debconf helper and especially the perl > db_stop, with the shell debconf helper. Can this be ? It's certainly possible, although those particular two confmodule libraries are fairly well-tested and I think other things use them that way round. I'd try removing the STOP command first. > Do we have some kind of documented spec of how these helpers do handle the > debconf interaction, or something, which would enable to investigate this > issue without lengthy error-and-trial ? debconf-devel(7) documents a lot of it here and there, but it's not really in the form of a strict design document or anything. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
