Hi Sam, On Mon, 2019-12-02 at 15:25 -0500, Sam Hartman wrote: > > > > > > "Ansgar" == Ansgar <[email protected]> writes: > > Ansgar> 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 > > Ansgar> It's very likely not a no-op on systemd systems as > Ansgar> significantly more people somehow got systemd-shim installed > Ansgar> than had sysvinit-core, see for example [1] which shows that > Ansgar> somehow the "no-op" results in systemd-shim getting > Ansgar> installed (which caused problems in the past). > > Ansgar> Just because you don't observe unwanted behavior happening > Ansgar> right now on your system doesn't imply it doesn't exist. > Ansgar> And the unwanted behavior that you say wouldn't happen (as > Ansgar> it is supposedly a "no-op") happens on a scale larger than > Ansgar> the entire sysvinit user base here... > > Ansgar, you keep bringing this issue up.
Yes, I bring this up as at is one of the few concrete examples where we have alternatives that must be chosen at build time. I would like to see if the proposed resolution would help if similar issues would come up again. > And it keeps coming up as "Stuff might happen that we don't really > understand." For one of the problems (apt making unexpected decisions) that is pretty close to what is the case. We do find such issues again and again, including too late, i.e. only after a stable release, also for other packages that aren't related to init systems. > That's deeply unsatisfying to hear. > And I think it's deeply unsatisfying to you when you hear that people > talk about playing alternative games and assuming it's just going to > work out. Yes, I now understand that the proponent of proposal D would just dismiss concerns as "theoretical degradations" without even trying to understand the problem or even getting to a point where one would look at weighting different trade-offs to get a compromise solution. In this discussion I provided a popcon graph which shows that systemd- shim has significantly more installations than sysvinit-core; if you prefer inline numbers: for stretch there are 3335 systemd-shim installations and 775 sysvinit-core installations. So it looks like something isn't quite as wanted. (And likely not all 775 sysvinit-core installations even have systemd-shim, so the unwanted case is even a bit larger; I'm too lazy to check that right now.) But even getting some people to acknowledge this seems very hard. Please note there was also a tech-ctte bug about the "no-op" dependency on "systemd-shim | systemd-sysv" causing problems beyond theoretical degradations previously (#883573). But still this is given as an example of "changes I view as done with spite, which bring no or negligible benefit to systemd yet large detriment to other rc systems"[1]. So I believe proposal D wouldn't help with resolving conflicts at all and doesn't provide improvements on this front. I also tried some related things, including some proposals to improve systemd support via Policy proposals that don't even degrade support for sysvinit such as recommending to always include native systemd units where approporiate. That now went back to someone questioning whether one should recommend to (almost) *never* include native systemd units instead... That is not very motivating and I fear that proposal D will result in that happening for any "non-init-related declarative systemd facility" as well. That is no improvement over the status quo, but additional obstacles such as mandatory waiting times. The "being excellent to each other" part of the proposal also leaves a sour impression if the proponent doesn't seem interested to hold himself to his own requirements as you pointed out in [2] (and other people did so before), but asks these to be uphold by others. Altogether this convinced me to likely rate "D" and some other choices below "FD". I don't think they'll bring us forward, even if on paper they might look like they do. That's a change from my position in the 2014 GR where I ranked the option that included "Debian packages may require a specific init system [...] if [...] and no patches or other derived works exist in order to support other init systems in such a way to render software usable to the same extent" first (but which was defeated by the option having less requirements to not provide support for sysvinit). Ansgar [1]: https://lists.debian.org/debian-vote/2019/11/msg00386.html [2]: https://lists.debian.org/debian-vote/2019/12/msg00064.html
