std-init.sh could possibly be upstreamed

[Greg Price]

In invirt-base we have a file /lib/init/std-init.sh, which takes the example initscript at /etc/init.d/skeleton and turns its hairy logic into a library that can be sourced. The consequence is much shorter initscripts that consist almost entirely of the code that actually varies.

It'd be nice to upstream this into Debian; it should be useful for packages in general. Of our 20 initscripts,
 - 8 use std-init
 - 8 use config-init, which possibly should also go upstream but is more specialized
 - 4 use neither, of which 2 should use std-init and 2 should use config-init.

Attaching the current version of std-init.sh, since it's stable and short.

[Evan Broder (broder)]

Do you (or does anyone) have any suggestion on where in Debian this should get upstreamed to?

[Greg Price (gregprice)]

On Sat, Dec 06, 2008 at 08:23:13AM -0000, Evan Broder wrote:
> Do you (or does anyone) have any suggestion on where in Debian this
> should get upstreamed to?

/etc/init.d/skeleton is in the initscripts package, which is built
from sysvinit. So that may be the right place.

Greg

[Geoffrey Thomas (geofft)]

Is this still interesting given that the world has moved on to upstart, systemd, etc.? (i.e., is the correct answer for us to upstartify or systemdize our packages and forget about SysV-style initscripts?)

[Mitchell Berger (mitchb)]

Upstartifying or systemdizing our packages is probably the correct answer,
at least in so much as that the current thought is that we're moving on to
Precise next, and should modernize for it. I'm not sure whether Quentin
was planning to work on the init scripts as part of the scope of what he's
doing.

However, the question of whether this is still interesting to upstream really
has little to do with our software - we already have this code. If we expect
lots of other software to continue using SysV init scripts and not upgrading
for several years, then this might still be worthwhile. The flip side is that
I imagine most software that's going to stick with SysV init for a while is
going to do so because they don't feel like doing development on their
init script, in which case they won't use this.

[Greg Price (gregprice)]

I think Mitch's last point is the key here -- it's unlikely many
people after this point will be doing significant refactoring on SysV
init scripts or writing new ones.

This software was good work and a major improvement over the state of
common practice. Maybe if we'd upstreamed it much sooner, people
would have liked their initscripts better and not been as quick to go
for alternatives! But we didn't, they did, and its moment seems to
have passed.

Greg

[Geoffrey Thomas (geofft)]

So, not every system in the world has upstart or systemd. Is this refactoring sufficient that we can also come up with std-upstart or std-systemd.service or something? (Interestingly, does it make our own transition easier?)

If not, then I agree that WONTFIX is correct.