Bug#215549: Why should the postinst care if it is being confiugured or reconfigured?
On Thu, Jul 02, 2009 at 11:20:19AM -0700, Russ Allbery wrote:
> > 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.
This does give us a straightforward way to check for use cases for
'reconfigure' checks, though: grep -rl DEBCONF_RECONFIGURE /var/lib/dpkg/info/
Excluding the various X.org scripts which seem to have a single mention of
this variable somewhere in the common maintainer script include, I see the
following maintainer scripts using the variable on one system:
ca-certificates.config
dictionaries-common.config
libapache-mod-ssl.postinst
locales.postinst
slapd.config
slapd.postinst
tzdata.config
tzdata.postinst
In all of these, the principle reason for distinguishing appears to be to
avoid certain prompts that can be avoided in one case or the other, since
'reconfigure' is always an explicit user action and implies different
debconf settings.
I don't know if this is a compelling argument to standardize a 'reconfigure'
argument to the maintainer script, unless debconf itself is also going to be
more tightly integrated with dpkg in the future.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Reply to: