Summary
-----------
Neither of these
dh_installsystemd --name=foo
dh_installsystemduser --name=foo
will fail the build when the expected filename doesn't exist;
consequently, the Debian package silently does not include the
expected systemd service.

Test Case
------------
Let's use the debian-edu-install package since it is a simple package
that builds quickly,

Change the final line of debian/rules
-dh_installsystemd -pdebian-edu-install --no-start --name=debian-edu-testsuite
+dh_installsystemd -pdebian-edu-install --no-start --name=debian-edu-testsuite2

Build the package. The build completes successfully even though
debian/debian-edu-install.debian-edu-testsuite2.service doesn't exist
(debian/debian-edu-install.debian-edu-testsuite.service exists
instead).

The build log doesn't indicate a failure either, as these are the only
2 relevant lines emitted:
dh_installsystemd -pdebian-edu-install --no-start --name=xdebian-edu-firstboot
dh_installsystemd -pdebian-edu-install --no-start --name=debian-edu-testsuite2

What I Expect
-------------------
I expect the build to fail because if a package has a rule to install
a systemd service, that service needs to be installed.

I am filing this bug as RC level initially. I noticed this issue with
the lomiri-telephony-service package where the systemd user services
were never installed and the package maintainer was unaware of this
error. It meant the package did not work correctly, but that has been
fixed with lomiri-telephony-service 0.6.2-4.

If this bug fix causes one or more packages to FTBFS, that is a good
thing since it exposes a bug (probably an RC bug) in that package's
packaging.

Other Info
-------------
This bug might have been mentioned in
https://bugs.debian.org/1051743
https://bugs.debian.org/974009

Thank you,
Jeremy Bícha

Hi Jeremy

Thanks for filing the bug.

As you have seen, I unfortunately disagree with the severity.

Jeremy Bícha:


I agree with the summary. I want to add some context to this in the form
of #462389 + #932073. The bug talks about a different helper because
this is a general problem with all debhelper like commands.

I believe the test case to accurately portrait the issue without having
tested (based on the context links provided above).


Now this is where we come to the meat of the problem. I understand your
expectation, and I would like my tools to behave that way in general.

The problem here being that debhelper has generally been quite
laissez-faire with locating files in `debian/` (both with and without
`--name`). This means it is now common to do:

      dh_foo --name bar

And it works finds debian/pkg.bar.foo without failing when there is also
a libpkg1 and a libpkg1-dev without a debian/lib*.bar.foo (see #932073
msg #27). Implementing this would effectively mean that `--name` would
require people to use `-p` as well.

So it is not "just" a matter of making it mandatory and then it finds
only problems. It also triggers a lot of "false positives" in the eyes
of the people that would be on the receiving end.


Generally, I am not a fan of how `--name` works. Instead, I would rather
have something like #932152 - although that is difficult to retrofit
into `debhelper`.


Best regards,
Niels