Mat <mat@???> wrote:

>> That's the logical way to do it - the init script(s) should be part of the package. The downside of that is the requirement for every package maintainer (team) to understand and support multiple init systems - or for someone supporting an init system to become a maintainer on lots of packages.
>
> Indeed this is a much better way, and it also guarantees that init
> scripts remain in sync as packages receive updates.

I was only partly thinking about updates - though that's important. It also means that every package has a script - assuming that it's an expectation that "a package isn't complete without one". If init scripts were provided separately, then there'd be a disconnect between packages available, and scripts to start them.

Thinking a bit more though ...
This is also probably behind some of the "issues" identified. Making an init script isn't a core part of the developer's task, and it's easy to see how making one can become a bit of a "grab a template and fudge with it till it works" task tacked on sometime.
In the electronics world, there's an expression "now throw it in a tin box" referring to the way many projects may have elegant circuits and so on - but then get shoved in some basic box with little thought to the aesthetics of the mechanical design because the person making it is an electronics person, not a cabinet maker.

So there is probably some merit in someone with the skills, motivation, and time offering **CONSTRUCTIVE** support to improve them across multiple projects.