Tracking down the issue further, I think I have found the culprit and the
workaround.
Here is the full story of my workaround:
I had added the following lines in debian/rules for installing unit files
for a package which is not the main package, pynslcd package in my case,
along with other unit files for the main package, nslcd:
override_dh_installsystemd:
dh_installsystemd -pnslcd --name=k5start-nslcd
k5start-nslcd.service
dh_installsystemd -pnslcd --name=nslcd nslcd.service
dh_installsystemd -ppynslcd --name=k5start-pynslcd
k5start-pynslcd.service
dh_installsystemd -ppynslcd --name=pynslcd pynslcd.service
although this worked for the main package nslcd, dh_installsystemd gave
errors for the other package, pynslcd.
Debugging dh_installsystemd (via printf), I found out that the issue stems
from the install_unit function here:
sub install_unit {
my ($package, $script, $pkgsuffix, $path, $installsuffix) = @_;
$installsuffix = $installsuffix || $pkgsuffix;
my $unit = pkgfile($package, $pkgsuffix);
return if $unit eq '';
install_dir($path);
install_file($unit, "${path}/${script}.${installsuffix}");
}
pkgfile subroutine cannot find the unit file with the parameters I have
used in override_dh_installsystemd section if the package is not the main
package.
Since the unit file is empty, it does not go ahead with creating the
systemd directory and copying the unit file there.
pkgfile is looking for pynslcd.k5start-pynslcd.service and
pynslcd.pynslcd.service files instead of what I had created :
k5start-pynslcd.service and pynslcd.service respectively.
Hence I renamed my files and the problem is solved.
However, since above lines used to work with dh_installinit, I believe it
is confusing how one should name her unit files.
Best Regards,
Emel
