[Debconf-devel] using debconf outside of config/postinst?

[Ian Campbell]

Or more precisely in places which may either be called from a postinst
or invoked from the CLI, dpkg triggers, hooks, other peoples postinsts
etc.

The context is the flash-kernel hook to mkinitramfs which contains on
fatal error:
        if [ "$DEBIAN_HAS_FRONTEND" ]; then
                echo "Unable to abort; system will probably be broken!" >&2
        else
                echo "Press Ctrl-C to abort build, or Enter to continue" >&2
                read _ignored
        fi
(until f-k 3.12 this was checking "$DEBIAN_FRONTEND" = "noninteractive",
which I think was wrong and led to #721485).

Is this allowable? It seems a bit sketchy to me, codesearch doesn't
exactly show any other instances (tasksel has something vaguely similar)

The intention is to not block waiting for stdin on failure in cases
where the user isn't watching. e.g. #721485 which is a case of the
installer silently hanging.

If the this sort of thing is allowable then is it safe/sane/allowed to
take it a step further and do in the DEBIAN_HAS_FRONTEND case:
        +               # No need to worry about confmodule re-execing the
        +               # script since we check $DEBIAN_HAS_FRONTEND
        +               # immediately above
        +               . /usr/share/debconf/confmodule
        +               # Make sure our templates are loaded
        +               db_x_loadtemplatefile $(dpkg-query --control-path flash-kernel templates) flash-kernel
        +               db_title flash-kernel
        +               db_subst flash-kernel/rootdev-error ROOTDEV $rootdev
        +               db_input critical flash-kernel/rootdev-error
        +               db_go
?

I had to manually load the templates for reasons I don't quite
understand (but which I strongly suspect are because this was run
outside of flash-kernel.{postinst,config}), my test case was:
        # cat s
        #!/bin/bash
        export DEBCONF_DEBUG=developer
        . /usr/share/debconf/confmodule
        update-initramfs -u
        exit 0

Since the primary use case is the installer, to warn that the
installation may not be successful, I could also investigate doing
something in flash-kernel-installer which would trigger the use of
debconf here instead. Which might be nicer? There is a danger that the
initramfs will be regenerated elsewhere due to triggers etc, although
perhaps it is unlikely to fail if it previously succeeded.

Ian.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/debconf-devel/attachments/20140112/5eb2dca6/attachment.sig>