debconf making package removal fail because of warnings issues by an earlier called program (in postrm) - Debian

This is a discussion on debconf making package removal fail because of warnings issues by an earlier called program (in postrm) - Debian ; CCing debian-devel Hi, An issue has been brought to my attention and I wonder, if this is a bug or the intended behaviour. For reference see https://bugs.launchpad.net/medibuntu/+bug/290621 . In this case a package should be removed. In its postrm it ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: debconf making package removal fail because of warnings issues by an earlier called program (in postrm)

  1. debconf making package removal fail because of warnings issues by an earlier called program (in postrm)

    CCing debian-devel

    Hi,

    An issue has been brought to my attention and I wonder, if this is a bug
    or the intended behaviour. For reference see
    https://bugs.launchpad.net/medibuntu/+bug/290621.

    In this case a package should be removed. In its postrm it calls
    update-mime-database, update-mime and some snippet by dh_installdebconf:

    > #!/bin/sh
    > set -ex
    > # Automatically added by dh_installmime
    > if [ -x "`which update-mime-database 2>/dev/null`" ]; then
    > update-mime-database /usr/share/mime
    > fi
    > # End automatically added section
    > # Automatically added by dh_installmime
    > if which update-mime >/dev/null 2>&1; then update-mime; fi
    > # End automatically added section
    > # Automatically added by dh_installdebconf
    > if [ "$1" = purge ] && [ -e /usr/share/debconf/confmodule ]; then
    > . /usr/share/debconf/confmodule
    > db_purge
    > fi
    > # End automatically added section


    Now one of the packages installed registered some MIME types with
    unregistered media types (in this case chemical-mime-data, but kde4 and
    some other packages do this too). So update-mime-database issues some
    warnings:

    > Unknown media type in type '...'


    (there is already an upstream bug report to not be that verbose here).
    And it seems, that this output "pollutes" debconf input:

    > + db_purge
    > + _db_cmd PURGE
    > + IFS= printf %s\n PURGE
    > + IFS=
    > read -r _db_internal_line
    > + RET=20 Unsupported command "unknown" (full line was "Unknown media
    > type in type 'chemical/x-alchemy'") received from confmodule.
    > + return 20


    The policy does not say, that programs called in the maintainer scripts
    are not allowed to be verbose or to issue warnings. There is a should
    but not a must to avoid this (3.9). But output seems to make debconf
    script(s) fail.

    I did not yet file a bug report. I want to hear some opinions first.
    Maybe I'm wrong with my opinion.

    Regards, Daniel


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  2. Re: debconf making package removal fail because of warnings issues by an earlier called program (in postrm)

    Daniel Leidert wrote:
    If I understand this case correctly then the problem is quite likely that
    this message

    >> Unknown media type in type '...'


    is output to stdout instead of stderr.

    Programs/scripts that have to be able to run under debconf are not allowed
    to output to or read input from stdout/stdin.

    If this is what's going on it's an RC bug in the relevant package.
    Possibly it can be worked around by redirecting its output at the call
    sites.

    But then again, I may have misunderstood this completely...

    Cheers,
    FJP

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEABECAAYFAkkIueIACgkQgm/Kwh6ICoSatQCgzavIIetTFNu3NI3BuiKsIEGB
    kNIAn1xmFcTeuoSSeHIY4MIVBmT7vVaC
    =L8gR
    -----END PGP SIGNATURE-----


  3. Re: debconf making package removal fail because of warnings issues by an earlier called program (in postrm)

    Frans Pop wrote:
    > Daniel Leidert wrote:
    > If I understand this case correctly then the problem is quite likely that
    > this message


    >>> Unknown media type in type '...'


    > is output to stdout instead of stderr.


    > Programs/scripts that have to be able to run under debconf are not allowed
    > to output to or read input from stdout/stdin.

    [...]

    Afaiui the program is not running /under/ debconf, it is started (and
    supposed to be stopped) before debconf is initialized.
    cu andreas

    --
    `What a good friend you are to him, Dr. Maturin. His other friends are
    so grateful to you.'
    `I sew his ears on from time to time, sure'


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  4. Re: debconf making package removal fail because of warnings issues by an earlier called program (in postrm)

    Am Mittwoch, den 29.10.2008, 20:30 +0100 schrieb Frans Pop:
    > Daniel Leidert wrote:
    > If I understand this case correctly then the problem is quite likely that
    > this message
    >
    > >> Unknown media type in type '...'

    >
    > is output to stdout instead of stderr.
    >
    > Programs/scripts that have to be able to run under debconf are not allowed
    > to output to or read input from stdout/stdin.


    update-mime-database is called inside the postrm (I posted the postrm in
    my mail) and issues some warnings. You can simply reproduce the issue by
    taking any package using debconf and adding an echo command to the
    postrm script:

    echo "Make me fail."

    And you should be able to reproduce the problem. E.g. use this postrm to
    reproduce:

    > #!/bin/sh
    > set -ex
    > echo "Make me fail."
    > # Automatically added by dh_installdebconf
    > if [ "$1" = purge ] && [ -e /usr/share/debconf/confmodule ]; then
    > . /usr/share/debconf/confmodule
    > db_purge
    > fi
    > # End automatically added section


    You don't need more. For some reason "Make me fail." is given as
    argument to the debconf confmodule:

    [..]
    > + db_purge
    > + _db_cmd PURGE
    > + IFS= printf %s\n PURGE
    > + IFS=
    > read -r _db_internal_line
    > + RET=20 Unsupported command "make" (full line was "Make me fail.") received from confmodule.
    > + return 20


    Regards, Daniel


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  5. Re: debconf making package removal fail because of warnings issues by an earlier called program (in postrm)

    Right. This is getting somewhat beyond my knowledge of debconf internals,
    but here is what happens.

    Daniel Leidert wrote:
    > You don't need more. For some reason "Make me fail." is given as
    > argument to the debconf confmodule:


    The full debug log and the sourced confmodule file fairly clearly show
    what happens.

    This is where the execution of the script starts:

    + echo 'Make me fail.'
    Make me fail.
    + '[' purge = purge ']'
    + '[' -e /usr/share/debconf/confmodule ']'
    + . /usr/share/debconf/confmodule

    Here confmodule is sourced. If you look at what it does when there is
    no frontend running yet, the behavior becomes clear:


    if [ ! "$DEBIAN_HAS_FRONTEND" ]; then
    PERL_DL_NONLAZY=1
    export PERL_DL_NONLAZY
    # Since there is no FrontEnd, this program execs a FrontEnd.
    # It will then run a new copy of $0 that can talk to it.
    if [ "$DEBCONF_USE_CDEBCONF" ]; then
    exec /usr/lib/cdebconf/debconf $0 "$@"
    else
    exec /usr/share/debconf/frontend $0 "$@"
    fi
    fi


    No frontend is yet running, so one is started and the script gets
    re-executed *under debconf*!

    ++ '[' '!' '' ']'
    ++ PERL_DL_NONLAZY=1
    ++ export PERL_DL_NONLAZY
    ++ '[' '' ']'
    ++ exec /usr/share/debconf/frontend ./test purge

    Which is exactly what happens here:

    + echo 'Make me fail.'

    So, we get another echo to stdout and _that_ is the one that causes
    the eventual error.

    + '[' purge = purge ']'
    + '[' -e /usr/share/debconf/confmodule ']'

    The next line is now basically a no-op as it has already been sourced:

    + . /usr/share/debconf/confmodule
    ++ '[' '!' 1 ']'
    ++ '[' -z '' ']'
    ++ exec
    ++ '[' '' ']'
    ++ exec
    ++ DEBCONF_REDIR=1
    ++ export DEBCONF_REDIR
    + db_capb
    + _db_cmd 'CAPB '
    + IFS=' '
    + printf '%s\n' 'CAPB '
    + IFS='
    '
    + read -r _db_internal_line
    + RET='20 Unsupported command "make" (full line was "Make me fail.")
    received from confmodule.'
    + case ${_db_internal_line%%[ ]*} in
    + return 20

    Don't ask me why this is done the way this is done, but AFAIK debconf has
    always worked this way. The correct version of your test script would be:


    #!/bin/sh
    set -ex

    . /usr/share/debconf/confmodule

    echo "Make me fail." >&2

    # Automatically added by dh_installdebconf
    if [ "$1" = purge ] && [ -e /usr/share/debconf/confmodule ]; then
    . /usr/share/debconf/confmodule
    db_capb
    fi
    # End automatically added section


    So, the automatic snippets work fine as long as they are the sole content
    of a maintainer script, but if not they need to be properly wrapped. And
    use of stdin/stdout is not allowed _anywhere_ in the script, even if it
    happens before debconf gets sourced (which is why for D-I we always
    source confmodule at the top of scripts).

    Maybe not intuitive, but that's life. And again, don't ask me why.

    /me suspects this may be cause for some nice mass-filing of RC bugs :-(

    Cheers,
    FJP

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEABECAAYFAkkI4fsACgkQgm/Kwh6ICoTCkACg1fOIYJiFcbsN097CsNSXNIAZ
    Uy4AoKNIZVwYPBdywNvq1ENqa+kzpX2D
    =QMUq
    -----END PGP SIGNATURE-----


  6. Re: debconf making package removal fail because of warnings issues by an earlier called program (in postrm)

    Am Mittwoch, den 29.10.2008, 23:21 +0100 schrieb Frans Pop:
    > Right. This is getting somewhat beyond my knowledge of debconf internals,
    > but here is what happens.
    >
    > Daniel Leidert wrote:

    [..]
    > The full debug log and the sourced confmodule file fairly clearly show
    > what happens.


    First thanks for your explanation. I will read it carefully. Just let me
    ask something about this statement:

    [..]
    > So, the automatic snippets work fine as long as they are the sole content
    > of a maintainer script, but if not they need to be properly wrapped. And
    > use of stdin/stdout is not allowed _anywhere_ in the script, even if it
    > happens before debconf gets sourced (which is why for D-I we always
    > source confmodule at the top of scripts).


    The policy states, that output by maintainer scripts and programs called
    in maintainer scripts "should" be avoided (3.9). There is no "must".
    Maybe you refer to prompting (3.9.1)? IMHO there can be many reasons,
    why a program may issue a note or a warning to STDOUT and except
    redirecting everything to /dev/null or STDERR we cannot make sure, that
    there is no output. So I think, that debconf needs a fix here.

    > Maybe not intuitive, but that's life. And again, don't ask me why.


    I agree, that this is not intuitive.

    > /me suspects this may be cause for some nice mass-filing of RC bugs :-(


    @debconf devs: A chance to fix this in debconf?

    Regards, Daniel


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

+ Reply to Thread