Bug#215549: Why should the postinst care if it is being confiugured or reconfigured?

[Russ Allbery <rra@debian.org>]

Manoj Srivastava <srivasta@golden-gryphon.com> writes:

>         The question is, why should we change something so deeply
>  deployed as package postinst API without compelling reasons that the
>  postinst should treat an upgrade differently from a reconfigure,
>  especially since the user interaction part is already correctly
>  handled by debconf?

Also, there's already a mechanism for postinst scripts to treat
reconfigure differently from configure if they absolutely have to.
Debconf sets DEBCONF_RECONFIGURE in the environment.  The documentation
says this is a hack until reconfigure is supported:

    Debconf sets DEBCONF_RECONFIGURE=1 before running postinst scripts,
    so a postinst script that needs to avoid some expensive operation
    when reconfigured can look at that variable. This is a hack because
    the right thing would be to pass $1 = "reconfigure", but doing so
    without breaking all the postinsts that use debconf is
    difficult. The migration plan away from this hack is to encourage
    people to write postinsts that accept "reconfigure", and once they
    all do, begin passing that variable.

but given how long we've been going with that being the supported way of
doing this, and given that we're not coming up with a lot of compelling
reasons why reconfigure should be different than configure, maybe we
should just bless that as the official mechanism.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>