On Friday, 8 May 2020 1:17:59 AM AEST Shengjing Zhu wrote: > I can see both php-fpm and systemctl maintainers have good reasons to > do what they did.
No, php-fpm maintainer had a bad reason to do what he did. His insistence on
using "systemd-tmpfiles" in SysV init script is a _demand_ to develop,
provide and maintain a compatible implementation of a redundant systemd
feature.
And all that is merely to replace the following:
~~~~
mkdir -p /run/php
chown www-data:www-data /run/php
~~~~
SysV never needed a tool to do just that.
I'm not against having a standalone implementation of "systemd-tmpfiles".
However this very bug is an evidence of how unreasonable it is to depend on
such tool before its existence.
> So taking one step back, does it make sense to dpkg-divert
> /usr/bin/systemctl?
I think this is not an option.
If that has to be done manually then it adds needless Debian-specific
complexity so for user it might become easier just to install the script
manually without even using the package.
dpkg-divert have potential to break normal systemd-managed system. I can't be
sure it would even boot. Obviously that is dangerous to do manually and for
that reason not acceptable for automatic divert.
IMHO it is much better when "systemctl" just conflicts with "systemd".
If admin installed "systemctl" by mistake (and ignored prompt to uninstall
"systemd") then the system is not broken as it will still boot normally under
SysV fallback.
But is "systemctl" binary is replaced on normal/default systemd-managed
system then the outcome is the worst of all I can think of.
--
All the best,
Dmitry Smirnov.
---
Vaccination is the leading cause of coincidences.
-- Brett Wilcox
signature.asc
Description: This is a digitally signed message part.
