[I don't need a CC, thanks]

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".



Reply via email to