Hello, 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 the expectations. 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 debian/foo.service 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 dh_installsystemd foo.service 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 path. 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. Cheers, Dan _______________________________________________ Pkg-systemd-maintainers mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
