[debhelper-devel] Bug#870768: debhelper: dh_systemd_enable generates maintscript code for all units despite --name parameter

[Luca Boccassi]

Package: debhelper
Version: 10.2.5
Severity: normal
Tags: patch

Dear maintainer,

When a package ships multiple units, and it uses dh_systemd_enable with
the --name parameter, eg with:

  debian/pkg1.foo1.service
  debian/pkg1.foo2.service

And calling:

override_dh_systemd_enable:
  dh_systemd_enable --name=foo1 --no-enable
  dh_systemd_enable --name=foo2

All calls act on all units despite the --name parameter. When using
additional parameters, such as --no-enable, the second call for foo2
will also write the maintainer script's snippet for foo1, enabling it,
despite the earlier --no-enable.

If the caller further restricts the run by passing the filename as
unnamed argument, which is redundant given the name of the file, then
false positive warnings are emitted at build time:

[  91s] dh_systemd_enable --name=foo1 foo1.service
[  91s] dh_systemd_enable: Could not find "foo1.service" in the
/lib/systemd/system directory of pkg2. This could be a typo, or using
Also= with a service file from another package. Please check carefully
that this message is harmless.
[  91s] dh_systemd_enable: Cannot open(foo1.service) for extracting the
Also= line(s)

Only by further restricting the run by passing -p pkg1 then this
warnings do not appear, as the helper will not try to find the units in
pkg2. Again this is redundant information, given the file is named
after the package it is supposed to be installed to.

A small patch is attached inline to fix this by restricting the sets of
units the helper acts on when --name is passed. Please do double, nay
triple check my Perl/regex though :-)

Thanks!

-- 
Kind regards,
Luca Boccassi


From e024276a141cb0b308e0cac6d9004cd479eb7546 Mon Sep 17 00:00:00 2001
From: Luca Boccassi <luca.boccassi at gmail.com>
Date: Fri, 4 Aug 2017 21:51:46 +0100
Subject: [PATCH] dh_systemd_enable: if --name is used act only on that unit

A possible use case when using --name is having multiple units:
  debian/pkg.foo1.service
  debian/pkg.foo2.service
and calling the helper twice:
  dh_systemd_enable --name=foo1 --no-enable
  dh_systemd_enable --name=foo2
in which case the snippets would be duplicated in the maintainer
scripts.
This becomes a bug when different parameters are used in each call,
eg: --no-enable, which gets overridden by generated code from the
second call and stealthly enabled against the wishes of the caller.
---
 dh_systemd_enable | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/dh_systemd_enable b/dh_systemd_enable
index c06f3c0f..a2fe9e79 100755
--- a/dh_systemd_enable
+++ b/dh_systemd_enable
@@ -217,6 +217,18 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
 		@args = grep !/(^|\/)$x$/, @args;
 	}
 
+	# If --name was used, act only on matching units. A typical use case is having
+	# multiple units per package named debian/pkg.foo1.service debian/pkg.foo2.service
+	# and calling the helper twice:
+	#   dh_systemd_enable --name=foo1 --no-enable
+	#   dh_systemd_enable --name=foo2
+	# in which case the snippets would be duplicated in the maintainer scripts without
+	# this filtering. This becomes a bug when different parameters are used in each
+	# call, eg: --no-enable, which gets overridden by generated code from the second call.
+	if (defined $dh{NAME}) {
+		@args = grep /(^|\/)$dh{NAME}\.(mount|path|service|socket|target|tmpfile)$/, @args;
+	}
+
 	for my $name (@args) {
 		my $base = basename($name);
 
-- 
2.11.0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/debhelper-devel/attachments/20170804/6f5a519b/attachment-0002.sig>