[Pkg-sysvinit-devel] Bug#826215: init-d-script as default skeleton (was: Re: Bug#826215: SysV init scripts using ...)

[Andreas Henriksson]

Hello.

On Fri, Jun 03, 2016 at 11:54:02PM +0200, Petter Reinholdtsen wrote:
> [Michael Biebl]
> > Petter, do you have any preference regarding those two proposals or do
> > you have another suggestion how we could address this?
> 
> I wrote
> <URL: http://people.skolelinux.org/pere/blog/Debian_init_d_boot_script_example_for_rsyslog.html >
> to explain the background for the init-d-script setup.
> 
> The goal is to avoid code in the individual init.d scripts that is not
> _required_ to get them working, to make it possible to fix bugs in many
> scripts by modifying one file.  Moving code from init-d-script to the
> individual init.d scripts thus seem like a step backwards.
[...]

Maybe I'm going further off-topic here, but have to ask something...

While I think that in theory init-d-script is a good idea, I have
some practical concerns about it being the default skeleton for now.

I agree that it would feel like a step backwards to revert to
the old skeleton, but at the same time as more packages pick up the
new skeleton they run into issues and there's no maintainer....

The only good thing I have to add about the old style is that atleast
it's well proven.... Personally I'd prefer if also init scripts where
something included in upstream collaboration, and wondering if that's
even possible with init-d-script (which I guess is only available in
Debian(-derivates))? There's also the question on where things should
live to avoid having all packages shipping an init script need to
depend on sysvinit. Also I doubt there will be any effort to convert
existing init scripts over to the new format so that it actually
gets the practical benefits of being able to fix many packages at once.
It's also risking becoming a situation where noone dares to touch the
"one place" (init-d-script itself) which affects all packages because
there's always something which breaks and given enough breakages people
will just move away from it. Having a good test-suite is as I see it
basically a requirement for doing these central backend code efforts,
cf. cdbs vs dh. People will quickly start relying on bug-compatibility
and implementation details when they need a solution to their problem
and there's noone around to quickly fix up the backend to work as
expected, see #825870 for a recent example of where I myself is guilty
of misleading someone into relying on implementation details
instead of using the (non-working) documented correct solution.

Each of these issues might be no big deal on their own but at the same
time it feels like there's bigger picture to be seen by someone thinking
about this system and how it would fit in both in Debians
multi-init-system world and how it would fit into upstream project
collaboration. That's not something that should be dealt with through
targeted NMUs in my opinion.

Until there's someone actively maintaining sysvinit (and init-d-script
in particular) I'd prefer we revert the skeleton back to the old version
for now. Opinions/Comments?

Regards,
Andreas Henriksson