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 [cjwatson@debian.org]

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}
');
> + 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-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120309151522.GG22155@rivendell.home.ouaza.com">h ttp://lists.debian.org/20120309151522.GG22155@rivendell.home.ouaza.com

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 [cjwatson@debian.org]

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}
');

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

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$fileE$/, @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 [cjwatson@debian.org]


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120312104448.GJ3450@riva.dynamic.greenend.org.uk ">http://lists.debian.org/20120312104448.GJ3450@riva.dynamic.greenend.org.uk