Re: dpkg-reconfigure does not set DPKG_MAINTSCRIPT_PACKAGE (et al)
On Fri, 2011-08-05 at 12:50:22 -0400, Joey Hess wrote:
> I keep seeing people complain that this bug is not fixed, but every
> time I look at it, I find myself unable to fix it, and with issues like
> * Where are these variables documented?
> (Appears that they're basically not, which makes it sorta hard to
> know that they are being set, or used, as intended.)
man dpkg (ENVIRONMENT section).
> * How is debconf supposed to set DPKG_MAINTSCRIPT_ARCH? If it has to call
> dpkg --print-architecture every time, that just makes every run slower,
> which would seem to be the opposite of the point of having such a
> variable in the first place. But it cannot be that simple anyway, with
> multiarch. What uses DPKG_MAINTSCRIPT_ARCH anyway?
That variable should match the architecture of the owning package not
the one of dpkg itself. The dpkg database should have knowledge about
this, as the script is already using dpkg --status getting the
Architecture should be trivial. The variable makes it easier to share
the same unmodified maintainer script for multiple architectures, of
course another solution would be to substitute it at build time from
a template or similar.
> * What should DPKG_MAINTSCRIPT_NAME be set to when the config script
> is being run?
config or postinst, depending on what's being called.
> * How is it appropriate for dpkg-maintscript-helper etc to be already using
> these variables when debconf is not yet setting them? Would it make
> more sense for dpkg-reconfigure to not set them, and
> dpkg-maintscript-helper etc to be a no-op when a package is being
Well I guess it can be argued that's the problem with external programs
using the dpkg namespace and using internal interfaces. Regardless, we
should take another look at trying to merge dpkg-reconfigure back somehow.
I think the scripts should behave the same whenever they are being
> * Nobody has ever addressed my concern that, if dpkg-reconfigure runs
> dpkg --configure --pending, this will result in it confusingly doing
> other things than configuring the specified package.
I don't remember what this is about, will check the bug report later.