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