Simon McVittie:
[...]
I've had discussions similar to this one as a dbus maintainer, since
dbus-daemon is another package with a tmpfiles.d fragment that is
affected by this change. I don't think this is as simple as either of
the two obvious opposing viewpoints:
- this dependency is always OK, take no action
- this dependency is always wrong, revert the feature completely
[...]
I think it would make sense for dh_installtmpfiles to have two modes:
- Assume tmpfiles.d snippets are required for the package's functionality
- Generate a dependency on a tmpfiles.d implementation
- Run it unconditionally
- Assume tmpfiles.d snippets are nice-to-have
- Generate a Suggests or Recommends on a tmpfiles.d implementation,
or no dependency relationship at all
- Only run it if one is installed
[...]
Hi,
Thanks to all for their input. I have read some of the further emails
(like Ansgar's two types of tmpfiles and Colin Watson's proposed patch)
and my reply also cover a bit of those despite not being a direct reply
to those concrete emails (threading-wise).
Also, thanks to Colin for taking the time to write a proposed patch.
While I hope to solve the problem in a different way, I very much
appreciated the gesture and effort.
While I agree with such modes could exist, I do not see what makes them
worth the effort it require to code/maintain and teach "every" Debian
contributor/debhelper user about (fsvo "every"). More so if it is an
option the maintainer has to provide to dh_installtmpfiles in some cases
as I feel we already require way to many brain cells from maintainers to
keep track of all the packaging complexity.
As I see it, the simplest solution - both implementation-wise and
cognitive-load-on-maintainer-wise is to go back to a runtime check that
asserts 'if [ -x "$(command -v systemd-tmpfiles)" ] ; then ... fi'
(instead of asserting we are running under systemd, which was the
previous check).
It would go back to the previously known status quo (except also fixing
#1013969), which has worked for years. Whatever used to work would still
work. We would not introduce any new load on to maintainers and we avoid
the "buildd images blow up" issues triggered via passwd.
The primary downside I see is that stuff might break if you are not
running our default init-system because you are not guaranteed to have
systemd-tmpfiles there.
However, it is not a regression. Additionally, I feel this case falls
under "Those interested in exploring such alternatives need to provide
the necessary development and packaging resources to do that work."
statement[1]. Given the "necessary development" can now be as simple as
installing the standalone version of systemd-tmpfiles I feel this is
quite acceptable on a trade-off scale.
Admittedly, if I could avoid this downside without introducing an
command line option, I might be swayed (depending on the exact idea).
But I cannot see a command line option being a net positive here on
"total energy spent vs. actual benefit" for the Debian project as a whole.
In summary, I think a runtime check for systemd-tmpfiles is the lesser
evil for this case and that should be our solution to this problem.
Thanks,
~Niels
[1]: https://www.debian.org/vote/2019/vote_002
