This near the freeze, is probably a horrible time for me to be thinking
about this type of thing, and I won't be too suprised if I wake up
tomorrow morning to find a black helicopter on the lawn and some big
burly guys with guns who watch my every move to make sure I am not
hacking on debconf[1], but..
I am considering completly changing how debconf communicates with
programs that use it. The idea of using stdin and stdout seemed great.
It was pretty clean and elegant. At the same time, it forced people to
stop violating policy by making postinsts print out the reams of
debugging information they all to often output.
Unfortunatly, the reality was somewhat more complex. The debconf
protocol, while quite simple to speak by hand, still was complex enough
to make libraries to speak it for you worthwhile. And developers still
wanted their postinst to output every niggly little detail of their
life. And they found all sorts of hacks to let them keep doing so, and
still use debconf (mostly involving stderr). Some even had the temerity
to file bugs about this (#50595). Debconf's insistance on using stdio for
its own purposes even crippled the most common library for speaking the
debconf protocol, the shell library (/usr/share/debconf/confmodule), so it
could not work in the most intuitive fashion.
But I was willing to live with all that. It was a fairly minor amount of
cruft. No, I started thinking about this change for more personal
reasons: a package of mine (base-config) that was pretty severly hobbled
by debconf's co-option of stdin/out. Base-config, you see, needed to use
debconf in its postinst, then use apt to install some packages, which
also use debconf, then use debconf some more. This proves impossible to
do cleanly as things stand now, and the postinst is a gawdawful hack. I
hate having cruft in one package I maintain merely to work around
another package I maintain. So I'm thinking about changing it.
The best new interface I have been able to come up with is this: Debconf
will speak the same protocol, but it will do it over a different file
descriptor. When debconf is running, $DEBCONF will be set to the
number of the file descriptor to use to communicate with debconf
(actually a socket). So, talking to debconf raw, which used to be this:
echo INPUT medium foo/bar
read ret
(Has anyone except for me and the debian-installer project ever written
code that does this? If it is in debian, this change would break it.)
Will change to this:
echo INPUT medium foo/bar >&$DEBCONF
read ret <&DEBCONF
Of course, one is free to run 'exec 0<&$DEBCONF_SOCKET 1>&$DEBCONF_SOCKET'
and then just talk to it on stdin and stdout as in the first example
above.
If I make this change, /usr/share/debconf/confmodule will maintain the
same interface (one of the nice things about having libraries to
communicate with debconf after all), but I will be able to introduce a
new shell library, which would change this:
. /usr/share/debconf/confmodule
db_input medium foo/bar
db_go
db_get foo/bar
if [ "$RET" = true ]; then
...
To this:
. /usr/share/debconf/lib
INPUT medium foo/bar
GO
if [ "`GET foo/bar`" = true ]; then
...
That addresses half a dozen design infelicities[2] in the current shell
library..
--
see shy jo
[1] Or maybe if they can't scramble the helis from .au by tomorrow
morning, a freeze announcement instead? ;-)
[2] The one longstanding gripe about use of debconf in postinst that this
does _not_ address is the way a postinst that starts an ill-behaved
daemon that does not close all low numbered fd's can appear to lock up.
Tough. daemon(3) exists for a reason.