On Friday, October 4th, 2024 at 5:13 PM, Niels Thykier <ni...@thykier.net> wrote:
> > > Daniel Markstedt: > > > Package: debhelper > > Version: 13.20 > > Severity: important > > > > Dear maintainers, > > > > I'm doing packaging for a project that has multiple packages, each with one > > systemd unit file. > > The dh_installsystemd debhelper picks up on the unit files and start > > processing them, but soon hits an error where it tries to process a unit > > file for package A that belongs to package B. > > > > This is a debuild log snippet leading up to the error: > > > > make[1]: Leaving directory '/home/dmark/salsa/netatalk'dh_installchangelogs > > -O--buildsystem=meson+ninja > > dh_installman -O--buildsystem=meson+ninja > > dh_installinit -O--buildsystem=meson+ninja > > dh_installsystemd -O--buildsystem=meson+ninja > > dh_installsystemd: error: Package 'a2boot' does not install unit > > 'atalkd.service'. > > make: *** [debian/rules:11: binary] Error 25 > > dpkg-buildpackage: error: debian/rules binary subprocess returned exit > > status 2 > > debuild: fatal error at line 1182: > > dpkg-buildpackage -us -uc -ui -i -I failed > > > > The corresponding debian/rules file looks like this: > > > > https://salsa.debian.org/netatalk-team/netatalk/-/blob/debian/latest/debian/rules > > > > As you can see, the upstream build system generates the unit files, which > > we then move into debian/ in an override in order for dh_installsystemd to > > pick them up. > > The end result lineup of files is correct to my best understanding of > > dh_installsystemd. > > > > A snippet from the top: > > > > [...] > > > > Do you have any idea if we are making some kind of mistake in our setup, or > > if this is a bug in the debhelper script? > > > > Right now we have a dirty workaround – 'dh_installsystemd || true' to > > ignore any error. > > The resulting packages look correct! > > > > Your support would be hugely appreciated. > > > > Sincerely, > > Daniel > > > Hi Daniel > > This is an explicit design choice related to `Also=` in systemd files. > The dh_installsystemd code has the following remark related to `Also=`. > > # Handle all unit files specified via Also= explicitly. This > # is not necessary for enabling, but for disabling, as we > # cannot read the unit file when disabling as it has already > # been deleted. The undocumented --no-also option disables > # handling of units linked via Also=. This option is provided > # only to suport a very specific use case in network-manager. > > So this problem occurs because `a2boot.service` has a > `Also=atalkd.service` line in it > (https://salsa.debian.org/netatalk-team/netatalk/-/blob/debian/latest/distrib/initscripts/systemd.a2boot.service.in#L19). > > I am not the strongest on systemd services and why this feature is > needed. If the above does not answer your questions, I recommend CC'ing > Luca Boccassi bl...@debian.org and asking them to clarify the > > situation and how to handle it. > > As noted, there is an undocumented `--no-also` option that disables this > check. But I do not know what breaks if you use it, so I would not > recommend using it without double checking with Luca first. > > Best regards, > Niels Hi Niels, This resolves the mystery, thank you. In this case, I am also the upstream maintainer of this project, so the easy solution is to remove "Also=" across the board from our systemd units. We originally applied "Also=" as a convenience for users to make sure service X is always enabled when enabling service Y,Z etc. for when managing systemd services manually. But since we learned now that it gets interpreted differently downstream, I think retiring it the best course of action. Thanks again! Daniel
signature.asc
Description: OpenPGP digital signature
