dh_installsystemd command line arguments handling
daniele at grinta.net
Sun Jun 10 19:51:03 BST 2018
please keep me in Cc, I'm not subscribed to the list.
I'm implementing user units support in dh_installsystemd. For doing so
the code needs a bit of refactoring and thus I'm trying to understand
how the tool is supposed to operate and adding some tests to check that
nothing will break in the process.
Command line arguments handling in dh_installsystemd is convoluted and
it does not seem correct in some cases. I would like to confirm what are
>From the man page, it seems that arguments are expected to be unit file
names, however the code supports specifying also unit files path
relative to the package root. The code does not distinguish between file
paths in the binary package build tempdir, or in the debian/ directory.
The handling of this later case seems however broken.
The tests setup in t/dh_installsystemd/dh_installsystemd.t defines one
source package "foo" generating three binary packages "foo", "bar",
"baz" and a "foo.service" unit file in the debian/ directory.
1. In one of the tests, dh_installsystemd is called with
"debian/foo.service" as an argument:
dh_installsystemd correctly picks up the foo.service from the debian/
directory and installs it in the foo package in the correct location,
and does not install it in the bar and baz packages.
However, dh_installsystemd also generates postinst blocks for enabling
and starting the foo.service unit for all the three packages. That does
not seem right.
2. If dh_installsystemd is instead called with the unit file name only
it fails because it is not able to find a foo.service unit for the bar
and baz packages.
3. The only correct invocation of dh_installsystemd is
dh_installsystemd -p foo foo.service
where dh_installsystemd is restricted to operate only on the foo binary
package which obviously contains a foo.service unit file in the expected
Which of those formats is supposed to be supported?
I think that the only supported arguments should be unit file names and
not relative paths (paths in the debian/ directory do not really make
sense as those are installed by dh_installystemd in the right place
already) and specifying absolute paths does not seem useful because unit
file names needs to be anyhow globally unique and thus there is an
unique mapping between unit file names and file paths.
I am not sure if dh_installsystemd should be smart enough to understand
on which binary package it should operate based on the unit file name,
to support case 2 above. The code is much simpler if that is not a
requirement, and explicit is better than implicit, so I'm temped to say
that the only accepted form in the case of a source package generating
multiple binary packages is case 3 above.
Cases 1 and 2 are already broken in the case of source packages
generating multiple binary packages, thus I hope there is anyone
relaying on that functionality.
More information about the Pkg-systemd-maintainers