[I don't need a CC, thanks] Hi,
I know it was mentioned back in the day, but trying to re-ask it now: Wouldn't it be possible to ship init scripts for compatibility purposes from a sysvinit (or maybe a sysvinit-support) package? This would be the inverse of what happened back when systemd was introduced, which was about shipping service files that superseded existing init scripts.
I have thought about this, and it seems like a bad idea for a number of reasons, including:
1) poor user experience - a package of initscripts would clutter /etc/init.d/ with a huge number of files (most of which would be no use to the user)
2) init scripts to need to change sometimes, typically that change will accompany a version change in the associated daemon (e.g. the CLI changes) - the most natural way to have this work seamlessly is for the init script to come with the daemon
3) many upstreams (esp. those who support BSD) ship a sysvinit file, again making the daemon (source at least) package the natural place to keep it.
4) difficulty reliably achieving seamless handoff from daemon package to a putative sysvinit-scripts package (e.g. packages that actively remove the init.d file from the installed system; keeping a users' modifications to the file)
I understand that you might not want that maintenance burden, however it seems like the network-manager maintainers might not want that maintenance burden either.
I think the burden concern is over-made here. This is not a case of "this init script has bugs that have been causing problems and no-one has fixed it", nor a bug report of the form "please write an init script". There is an extant, working init script. There are people more than happy to provide assistance should it need updating. I concede that collaborating with those people is non-zero effort, but this is not a case of "I want this work done and am not prepared to help do it".
Regards, Matthew