Bug#560317: dpkg-reconfigure does not set DPKG_MAINTSCRIPT_PACKAGE (et al)
On Mon, Mar 12, 2012 at 10:15:29AM -0400, Joey Hess wrote: Colin Watson wrote: How about this, then? Works for me.. OK, great. I've pushed that to master and will look at putting together an upload shortly ... Thanks, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560317: dpkg-reconfigure does not set DPKG_MAINTSCRIPT_PACKAGE (et al)
On Fri, Mar 09, 2012 at 12:36:06PM -0400, Joey Hess wrote:
It's a shame that dpkg-query is so slow. Cold cache (which will be
typical), it takes something like a second to run; warm cache around .3
seconds. Overhead includes reading the entire status file. The above
code runs it 5 times in all.
So, it would be worth only running it once and picking out the
appropriate filenames from its output.
How about this, then?
diff --git a/dpkg-reconfigure b/dpkg-reconfigure
index 4bb1525..9e27fde 100755
--- a/dpkg-reconfigure
+++ b/dpkg-reconfigure
@@ -183,10 +183,18 @@ foreach my $pkg (@packages) {
}
}
+ my @control_paths=`dpkg-query --control-path $pkg`;
+ map chomp, @control_paths;
+ sub control_path {
+ my $file = shift;
+ my $path = (grep /\.\Q$file\E$/, @control_paths)[0];
+ chomp($path) if defined $path;
+ return $path;
+ }
+
if ($reload) {
# Load up templates just in case they aren't already.
- my $templates=`dpkg-query --control-path $pkg templates`;
- chomp($templates);
+ my $templates=control_path('templates');
if ($templates and -e $templates) {
Debconf::Template-load($templates, $pkg);
}
@@ -201,8 +209,7 @@ foreach my $pkg (@packages) {
['config', 'reconfigure', $version],
['postinst', 'configure', $version]) {
my $script=shift @$info;
- my $path_script=`dpkg-query --control-path $pkg $script`;
- chomp($path_script);
+ my $path_script=control_path($script);
next unless $path_script and -x $path_script;
PS, cdebconf includes a dpkg-reconfigure now and will need the same
changes. Probably we need to make sure to communicate substantial
changes like this with Regis at least until cdebconf takes over from
debconf.
cdebconf is actually ahead of debconf on this right now: it already has
the 'dpkg-query --control-path' thing (and just runs it once per
script), and it also already sets the DPKG_MAINTSCRIPT_* variables. It
does need the triggers work, though. CCing Regis here.
--
Colin Watson [cjwat...@debian.org]
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560317: dpkg-reconfigure does not set DPKG_MAINTSCRIPT_PACKAGE (et al)
Colin Watson wrote: How about this, then? Works for me.. -- see shy jo signature.asc Description: Digital signature
Bug#560317: dpkg-reconfigure does not set DPKG_MAINTSCRIPT_PACKAGE (et al)
Hi all, On Mon, 2012-03-12 at 10:44 +, Colin Watson wrote: On Fri, Mar 09, 2012 at 12:36:06PM -0400, Joey Hess wrote: It's a shame that dpkg-query is so slow. Cold cache (which will be typical), it takes something like a second to run; warm cache around .3 seconds. Overhead includes reading the entire status file. The above code runs it 5 times in all. So, it would be worth only running it once and picking out the appropriate filenames from its output. PS, cdebconf includes a dpkg-reconfigure now and will need the same changes. Probably we need to make sure to communicate substantial changes like this with Regis at least until cdebconf takes over from debconf. cdebconf is actually ahead of debconf on this right now: it already has the 'dpkg-query --control-path' thing (and just runs it once per script), and it also already sets the DPKG_MAINTSCRIPT_* variables. It does need the triggers work, though. CCing Regis here. Thanks for the heads up. I was planning to do an upload of cdebconf tonight, so I think I'll be looking at the triggers stuff for dpkg-reconfigure after that. Regis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560317: dpkg-reconfigure does not set DPKG_MAINTSCRIPT_PACKAGE (et al)
On Fri, Aug 05, 2011 at 09:57:33PM +0200, Raphael Hertzog wrote:
On Fri, 05 Aug 2011, Joey Hess wrote:
* 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 believe this should simply be documented. I rarely run dpkg-reconfigure
on a system that's not clean from an installation point of view.
But if you really want to try to limit the side effects then you can compare
the status of all packages before and after having run the scripts and decide
whether or not you have to run it. You could also try to configure only the
affected packages but since triggers processing can activate other triggers,
you might have to fallback to --configure --pending anyway if it turns out
it was not enough.
I would add a couple of things:
* There's nothing stopping a package using 'dpkg-trigger
--by-package=PACKAGE' in its postinst right now (it's redundant but
permissible), so we might well have this problem already even without
setting these environment variables. Fundamentally since we're
running the postinst by hand it seems as though we're responsible for
cleaning up after it too.
* There already exist packages which test for DEBCONF_RECONFIGURE or
DPKG_RUNNING_VERSION or some such before running dpkg-trigger, and if
set they just perform the action immediately rather than triggering.
That won't be broken by this change, and at least in the case of
self-triggers it's a perfectly reasonable package-level approach.
(Many non-self-triggers are guarded by version checks anyway which
won't fire on reconfigure, such as the perl-major-upgrade one.)
* The dpkg-maintscript-helper issue seems more pressing to me right now
than the dpkg-trigger one, since .maintscript files (for which I
added support to dh_installdeb a while back without thinking about
this bug) are becoming more popular and will cause this kind of
problem. But I agree that we at least need not to make matters worse
regarding dpkg-trigger.
* I do tend to agree with Joey that 'dpkg --configure --pending' seems
a little bit over the top.
I applied Raphaël's first two patches to a local branch, fixed up a
couple of typos in the second, and added a patch of my own which
calculates the set of packages with newly pending triggers after running
maintainer scripts and configures them until there are no newly pending
triggers. This seems to behave well for me and doesn't seem too
unreasonable a solution, particularly since you get Processing triggers
for PACKAGE ... at the top of the output from dpkg so it's clear what's
happening. The result of this work is attached, minus changelog which I
can write up if this is acceptable.
Joey, would you be OK with this approach?
Thanks,
--
Colin Watson [cjwat...@debian.org]
From 4628727338951178308d957b7c8bf9ad927f6bce Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= hert...@debian.org
Date: Fri, 5 Aug 2011 21:21:13 +0200
Subject: [PATCH 1/3] Set environment variables expected by maintainer scripts
Closes: #560317
---
dpkg-reconfigure |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/dpkg-reconfigure b/dpkg-reconfigure
index e38df69..b433bb0 100755
--- a/dpkg-reconfigure
+++ b/dpkg-reconfigure
@@ -170,6 +170,8 @@ foreach my $pkg (@packages) {
$_=`dpkg --status $pkg`;
my ($version)=m/Version: (.*)\n/;
my ($status)=m/Status: (.*)\n/;
+ my ($package)=m/Package: (.*)\n/;
+ my ($arch)=m/Architecture: (.*)\n/;
if (! $force) {
if (! defined $status || $status =~ m/not-installed$/) {
print STDERR $0: .sprintf(gettext(%s is not installed), $pkg).\n;
@@ -200,6 +202,11 @@ foreach my $pkg (@packages) {
my $is_confmodule='';
+ # Set environment variables expected by maintainer scripts
+ $ENV{DPKG_MAINTSCRIPT_PACKAGE}=$package;
+ $ENV{DPKG_MAINTSCRIPT_ARCH}=$arch;
+ $ENV{DPKG_MAINTSCRIPT_NAME}=$script;
+
if ($script ne 'config') {
# Test to see if the script uses debconf.
open (IN, $infodir/$pkg.$script);
--
1.7.9.1
From 3489fc62f2ab7b9235ba2f431601e8f3ed0fbafb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= hert...@debian.org
Date: Fri, 5 Aug 2011 21:27:06 +0200
Subject: [PATCH 2/3] Do not hardcode the path of maintainer scripts
Multi-arch changes the layout for Multi-Arch: same package
and it's thus important to use the official dpkg interface
to retrieve the path.
---
dpkg-reconfigure | 21 -
1 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/dpkg-reconfigure b/dpkg-reconfigure
index b433bb0..daa7bee 100755
--- a/dpkg-reconfigure
+++ b/dpkg-reconfigure
@@ -85,8 +85,6 @@ if (exists $ENV{DEBCONF_USE_CDEBCONF} and $ENV{DEBCONF_USE_CDEBCONF} ne '') {
exec /usr/lib/cdebconf/dpkg-reconfigure, @ARGV;
}
-my $infodir=/var/lib/dpkg/info;
-
Bug#560317: dpkg-reconfigure does not set DPKG_MAINTSCRIPT_PACKAGE (et al)
On Fri, 09 Mar 2012, Colin Watson wrote:
happening. The result of this work is attached, minus changelog which I
can write up if this is acceptable.
Thank you for this! A quick comment though:
+# Returns a list of all packages with pending triggers.
+sub triggers_pending {
+ my @ret;
+ local $_;
+
+ open (QUERY, '-|', 'dpkg-query', '-W',
+ '-f', '${Package} ${Triggers-Pending}\n');
+ while (QUERY) {
+ my ($pkg, @triggers) = split;
+ push @ret, $pkg if @triggers;
+ }
+ close QUERY;
To be fully multi-arch compliant, you should in theory use
${binary:Package} instead of ${Package}. That way multi-arch: same
package will be arch-qualified.
But for backwards compatibility, you'll have to detect when
it's available. (And just testing dpkg --assert-multiarch will
break on Ubuntu since the current multiarch implementation there
doesn't know this field under this name)
The easiest is to put both fields in the query and to use the one
that's not empty.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560317: dpkg-reconfigure does not set DPKG_MAINTSCRIPT_PACKAGE (et al)
On Fri, Mar 09, 2012 at 04:15:22PM +0100, Raphael Hertzog wrote:
To be fully multi-arch compliant, you should in theory use
${binary:Package} instead of ${Package}. That way multi-arch: same
package will be arch-qualified.
Fair enough. Amended patch attached.
Thanks,
--
Colin Watson [cjwat...@debian.org]
From fd822639c3cb49fe1f0d7fe004834c27e02dba8a Mon Sep 17 00:00:00 2001
From: Colin Watson cjwat...@debian.org
Date: Fri, 9 Mar 2012 14:32:07 +
Subject: [PATCH 3/3] Process any newly pending triggers after running
maintainer scripts
---
dpkg-reconfigure | 39 +++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/dpkg-reconfigure b/dpkg-reconfigure
index daa7bee..4bb1525 100755
--- a/dpkg-reconfigure
+++ b/dpkg-reconfigure
@@ -159,6 +159,8 @@ else {
# hysterical raisens.
$ENV{DEBCONF_RECONFIGURE}=1;
+my %initial_triggers=map { $_ = 1 } triggers_pending();
+
foreach my $pkg (@packages) {
# Set default title.
$frontend-default_title($pkg);
@@ -255,6 +257,23 @@ foreach my $pkg (@packages) {
}
}
+# Maintainer scripts may have activated triggers. If so, try to process
+# them.
+my @new_triggers;
+do {
+ @new_triggers=();
+ foreach my $trigpend (triggers_pending()) {
+ push @new_triggers, $trigpend
+ if not exists $initial_triggers{$trigpend};
+ }
+ if (@new_triggers) {
+ my $ret=system(dpkg, --configure, @new_triggers);
+ if (int($ret / 256) != 0) {
+ exit int($ret / 256);
+ }
+ }
+} while (@new_triggers);
+
$frontend-shutdown;
Debconf::Db-save;
@@ -275,6 +294,26 @@ sub allpackages {
return sort @ret;
}
+# Returns a list of all packages with pending triggers.
+sub triggers_pending {
+ my @ret;
+ local $_;
+
+ open (QUERY, '-|', 'dpkg-query', '-W',
+ '-f', '${Package} ${binary:Package}\t${Triggers-Pending}\n');
+ while (QUERY) {
+ my ($pkgnames, $triggers) = split /\t/;
+ if (length $triggers) {
+ # Handle multiarch.
+ my ($pkg, $binpkg) = split ' ', $pkgnames;
+ push @ret, (length $binpkg ? $binpkg : $pkg);
+ }
+ }
+ close QUERY;
+
+ return @ret;
+}
+
=head1 AUTHOR
Joey Hess jo...@debian.org
--
1.7.9.1
Bug#560317: dpkg-reconfigure does not set DPKG_MAINTSCRIPT_PACKAGE (et al)
Colin Watson wrote:
+ my $templates=`dpkg-query --control-path $pkg templates`;
+ my $path_script=`dpkg-query --control-path $pkg $script`;
+ open (QUERY, '-|', 'dpkg-query', '-W',
+ '-f', '${Package} ${Triggers-Pending}\n');
It's a shame that dpkg-query is so slow. Cold cache (which will be
typical), it takes something like a second to run; warm cache around .3
seconds. Overhead includes reading the entire status file. The above
code runs it 5 times in all.
So, it would be worth only running it once and picking out the
appropriate filenames from its output. At least this would reduce the
number of runs to 3, and dpkg-reconfigure only gets 1.6 seconds slower,
rather than 2.2 seconds slower.
PS, cdebconf includes a dpkg-reconfigure now and will need the same
changes. Probably we need to make sure to communicate substantial
changes like this with Regis at least until cdebconf takes over from
debconf.
--
see shy jo
signature.asc
Description: Digital signature
Bug#560317: dpkg-reconfigure does not set DPKG_MAINTSCRIPT_PACKAGE (et al)
Hello. I have found this problem too. Is there some workaround that I can use so I can reconfigure a whole system I have? I want to review all the configuration and make changes where necessary. Has anyone with the required knowledge reviewed the patches made by Raphael Hertzog? Thanks a lot guys and sorry for disturbing. Have a nice day (and night)! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560317: dpkg-reconfigure does not set DPKG_MAINTSCRIPT_PACKAGE (et al)
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 these: * 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.) * 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? * What should DPKG_MAINTSCRIPT_NAME be set to when the config script is being run? * 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 reconfigured? * 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. -- see shy jo signature.asc Description: Digital signature
Bug#560317: dpkg-reconfigure does not set DPKG_MAINTSCRIPT_PACKAGE (et al)
Hi! 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 these: * 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 reconfigured? 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 called. * 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. regards, guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560317: dpkg-reconfigure does not set DPKG_MAINTSCRIPT_PACKAGE (et al)
Hi Joey,
On Fri, 05 Aug 2011, 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
these:
Thanks for looking into it!
* 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
[...]
DPKG_MAINTSCRIPT_PACKAGE
Defined by dpkg on the maintainer script environment to the
package
name being handled.
DPKG_MAINTSCRIPT_ARCH
Defined by dpkg on the maintainer script environment to the
architec-
ture the package got built for.
DPKG_MAINTSCRIPT_NAME
Defined by dpkg on the maintainer script environment to the
name of
the script running (preinst, postinst, prerm, postrm).
* 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?
Nothing uses DPKG_MAINTSCRIPT_ARCH yet, to the best of my knowledge. It has been
introduced for completeness in the multiarch world because
DPKG_MAINTSCRIPT_PACKAGE
might not be enough to precisely identify the package in the case of Multi-Arch:
same packages.
The goal of this variable was definitely not to be a cache for dpkg
--print-architecture. It should be set to the architecture of the package
(i.e. it can be all too).
So really the value you want is:
dpkg -s package-typed-by-user | awk '/^Architecture: / { print $2 }'
(you're already querying dpkg -s so it's fine to extract it too)
BTW, for multiarch compliance you should use dpkg-query --control-path
package-typed-by-user postinst to find out the path of the postinst script
(and similar for the config script).
I have attached 3 patches, you should consider at least the first two.
(Not tested though)
* What should DPKG_MAINTSCRIPT_NAME be set to when the config script
is being run?
config should be fine.
* 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
reconfigured?
I'm not sure we can answer this in the same way for all dpkg-maintscript-helper
sub-commands (existing and to come). Thus I prefer the statu quo over
arbitrarily deciding that being a no-op is ok when its action might be required
by something that happened earlier in the postinst.
* 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 believe this should simply be documented. I rarely run dpkg-reconfigure
on a system that's not clean from an installation point of view.
But if you really want to try to limit the side effects then you can compare
the status of all packages before and after having run the scripts and decide
whether or not you have to run it. You could also try to configure only the
affected packages but since triggers processing can activate other triggers,
you might have to fallback to --configure --pending anyway if it turns out
it was not enough.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
From 2d46466417d9f98012abd5ee126b48d54290776f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= hert...@debian.org
Date: Fri, 5 Aug 2011 21:21:13 +0200
Subject: [PATCH 1/3] Set environment variables expected by maintainer scripts
Closes: #560317
---
dpkg-reconfigure |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/dpkg-reconfigure b/dpkg-reconfigure
index e38df69..b433bb0 100755
--- a/dpkg-reconfigure
+++ b/dpkg-reconfigure
@@ -170,6 +170,8 @@ foreach my $pkg (@packages) {
$_=`dpkg --status $pkg`;
my ($version)=m/Version: (.*)\n/;
my ($status)=m/Status: (.*)\n/;
+ my ($package)=m/Package: (.*)\n/;
+ my ($arch)=m/Architecture: (.*)\n/;
if (! $force) {
if (! defined $status || $status =~ m/not-installed$/) {
print STDERR $0: .sprintf(gettext(%s is not installed), $pkg).\n;
@@ -200,6 +202,11 @@ foreach my $pkg (@packages) {
my $is_confmodule='';
+ # Set environment variables expected by maintainer scripts
+ $ENV{DPKG_MAINTSCRIPT_PACKAGE}=$package;
+ $ENV{DPKG_MAINTSCRIPT_ARCH}=$arch;
+ $ENV{DPKG_MAINTSCRIPT_NAME}=$script;
+
if ($script ne 'config') {
# Test to see if the script uses debconf.
open (IN, $infodir/$pkg.$script);
--
1.7.5.4
From
