Mat <m...@parad0x.org> 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. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
