On Wed, 2020-12-16 at 14:46 +0000, Matthew Vernon wrote: Not is it straightforwardly clear that "alternative init systems" should in fact be interpreted to mean "alternative init systems (but not sysvinit)".
The GR text mostly seems to talk about *exploring* alternatives; continuing to maintain a 30 year old system doesn't really seem explorative work to me? Even retiring sysvinit support completely seems fine with the GR's text. Besides preserving sysvinit in its current state (arguably not exploration), not much else seems to happen with regard to alternatives to systemd as far as I am aware? For exploration, much less support is needed: to install systemd-sysv you had to fight with dpkg to uninstall / keep away an essential package (sysvinit) for several years or choose alternative routes (e.g. specify init= on the kernel command-line); you might have needed to write .service units yourself to start services using systemd's native facilities instead of a (limited, but well-working) compatibility layer. I still have some custom .service units for packages that don't ship one themselves. Arguably having to create "fake" packages using `equivs` or similar tools to satisfy dependencies one would like to force to be avoided would be comparable to having to remove essential packages? Not having all packages ship a sysvinit script must also be more or less expected: we have 250+ packages shipping .service files, but no sysvinit scripts in current testing. I already filtered out any packages shipping DBus .service files and some packages part of the systemd/sysvinit implementation itself for this, but there are some other false postives like .timer units with their associated .service unit that have equivalent cronjobs (though some might miss a cronjob as well). For comparison: 980 packages in total have any .service system units and 1057 have a sysvinit script (excluding the packages part of systemd/sysvinit itself.) In addition some package use other systemd-provided facilities that elogind conflicts with, e.g., systemd-tmpfiles; or systemd-hostnamed here for NM (AFAIU). As you already said you would like the technical committee to rule that similar changes should not be blocked by maintainer of other packages and already said you have some packages in mind, I think it would be interesting to know which ones you are talking about. Would maintainers have to accept patches stopping use of systemd-tmpfiles, systemd-hostnamed, ...? Ansgar