On Wednesday, 6 May 2020 9:58:03 PM AEST Ansgar wrote: > > Clearly there is a problem in "php7.4-fpm" which should not depend on > > "systemd" in first place because it is perfectly functional without > > "systemd- tmpfiles" and without "systemd" as far as I can tell. > > It might or might not be; adding wrong dependency information to other > packages to work around that isn't a solution.
I insist that "adding wrong dependency information to other packages" is not a situation here, if you misled to think that from unfortunate changelog entry in "systemctl" package. > Though depending on packages required by startup scripts (init scripts > or systemd units) doesn't seem wrong for Debian packages, even when > specific use cases might not require it (when you provide your own, > different startup scripts). On this instance it is wrong. Suppose you install "php7.4-fpm" to run it with "runit" or "supervisor". In such situation it might be perfectly reasonable to have "broken" systemd because you would be starting "php7.4-fpm" using a custom service management script. However there will be serious problem if "runit" or "supervisor" conflicts with "systemd" -- that is exactly the situation with "systemctl" package that provides compatible interface with "systemd" to manage services with native .service files (with little or no modifications). > There also exist solutions like `equivs` for these cases. Which is absolutely not acceptable for "systemctl" package because "systemd" will not work with "bin/systemctl" binary from "systemctl" package. It would be far worse to break "systemd" by installing "systemctl" package along with it. Remember that "bin/systemctl" is _the_ interface to manage services under "systemd" and "systemctl". We do not have a problem with "Provides: systemd" in "systemctl" package on systems where "systemd" is installed by default because admins knowingly install "systemctl" in order to replace "systemd". We do not have a problem with "Provides: systemd" in "systemctl" package on systems where "systemctl" is installed from scratch to manage services without systemd hence avoiding installation of "systemd". I can't see where we would have a problem at all so I'll downgrade severity once again. > With php7.4-fpm 7.4.5-1 and systemctl 1.4.4181-1 installed in a current > Debian unstable: > > +--- > > | root@09f957efac98:/# /etc/init.d/php7.4-fpm start > | /etc/init.d/php7.4-fpm: 99: systemd-tmpfiles: not found > > +--- > > That's what the dependency is for and it's broken because of the > `Provides`. No, it is broken because of the bug in SysV init script which explicitly calls `systemd-tmpfiles` binary hence _requires_ systemd facility. Arguably it is a bad idea to hard-depend on "systemd" for SysV services and this is precisely the systemd zealotry that makes maintenance of alternatives so hard, creates bad reputation to Debian and poisons debates with toxic arguments... :( As I've said earlier, you would not install "runit", "supervisor" or "systemctl" to use foreign interfaces to manage services. Your example would have been more valid with `systemctl start php7.4-fpm` which needs a manual workaround to create `/run/php`. FYI I've reported this problem upstream: https://github.com/gdraheim/docker-systemctl-replacement/issues/98 However "systemctl" is not suppose to provide a 100% compatible implementation of systemd features and I hope we will not be arguing on what percentage of interface compatibility warrants "Provides". -- Cheers, Dmitry Smirnov. --- Some like to understand what they believe in. Others like to believe in what they understand. -- Stanisław Jerzy Lec
signature.asc
Description: This is a digitally signed message part.
