Adam Borowski writes: > * dependencies on "systemd | other" rather than "other | systemd"; this is > a no-op on a systemd system (installed by debootstrap before any > non-base packages) but causes apt to force an init+rc switch elsewhere
It's very likely not a no-op on systemd systems as significantly more people somehow got systemd-shim installed than had sysvinit-core, see for example [1] which shows that somehow the "no-op" results in systemd-shim getting installed (which caused problems in the past). Just because you don't observe unwanted behavior happening right now on your system doesn't imply it doesn't exist. And the unwanted behavior that you say wouldn't happen (as it is supposedly a "no-op") happens on a scale larger than the entire sysvinit user base here... Your policykit-1 example would likely also suffer from this: adding alternative builds doesn't only complicate packaging, but it makes the dependency relations more complicated. As we've seen from systemd-shim it's hard to get this right (and Debian did not get this right); from memory the policykit-1 dependencies to support alternatives looked more complicated and fragile than what we had for systemd-shim, so they would probably result in unwanted behavior more often. So the policykit maintainers wanting to avoid these problems is understandable to me (I don't think trying to force maintainers to accept such patches via a GR (option D) is a good solution either). It doesn't really help that you pretend that there are no issues with complex dependencies (as above). At a certain point it doesn't make sense to repeat saying that to you. [1]: https://qa.debian.org/popcon-graph.php?packages=sysvinit-core+systemd-shim&show_installed=on&want_legend=on&beenhere=1 > * recently added lintian warning requiring maintainers to add a redundant > .service file even if an init script it already there. It doubles the > work and makes one of methods not maintainer-tested (some folks won't > test init scripts, I won't test .service). And in most cases doesn't > even bring any good. Having multiple init systems that all just call the same sysvinit script without taking advantage that their native unit type (whatever it is) provides seems rather uninteresting to me. It would just mean we get different implementations that in the end call the same init scripts (so not "multiple implementations" at all). What would be the point of providing, for example, openrc be then? As you don't use systemd I also doubt you would know which (admittedly mostly minor) annoyances exactly systemd's sysv-compat layer can cause and would prefer if you didn't try to block people from improving things. Really, going back to a "should we really ship systemd units" discussion makes me wish we would just drop sysvinit completely so we don't have to restart any discussion from zero (or the point where any alternative init system was added to Debian). Ansgar
