Bug#835520: [PATCH 10/11] Replace init example by refering to dh-make

[Andreas Henriksson <andreas@fatal.se>]

Hello Andrey Rahmatullin.

Thanks for your input. (Did you also look at the other patches in the
series? Any objections or support for any of them?)

On Tue, Dec 06, 2016 at 07:21:00PM +0500, Andrey Rahmatullin wrote:
> On Tue, Dec 06, 2016 at 03:07:21PM +0100, Andreas Henriksson wrote:
> > The dh_make program should generate the current best practises
> > version 
> I'm not sure about this.
> And this is the first mention of dh_make in the policy except for a
> footnote about writing manpages.

I agree it feels a bit awkward for me to introduce dh_make, but the
alternative of not doing anything about the current paragraph is worse
in my opinion for the following reasons:

* it's not init agnostic (unlike dh_make which can give you a template
  for any current or future init systems without the need to update policy).
* the current /etc/init.d/skeleton is 'new-style' init script:
  + has very little track record of correctness (only used by very few
    packages at the moment)
  + is known to have several bugs, among them breaking compatibility
     with our current default init system.
  + is and was introduced as orphaned
(See existing sysvinit bug reports for further details.)

If we want to avoid mentioning dh_make I see the following options:
 - someone volunteers to adopt sysvinit et.al. and actually triages
   the bugs that has been reported against the current/new skeleton.
 - someone NMUs sysvinit making /etc/init.d/skeleton the old template again.

+ writes additional text for policy where you can find examples for
non-sysvinit init systems.

If you have to do it which one would you prefer to take on Andrey? ;)
(And do you see any other alternative solution you'd prefer to implement?)
Unless already obvious, my preference is to outsource to dh_make,
if I have to do the work myself. :)

Finally, the paragraph is just a note about where to find an(y) example.
In practise packaging often starts with dh_make anyway, so documenting
current practise is a useful goal to have in policy IMHO. Also, all the
changes I posted is mostly about pruning outdatedness. Additional work
on actually adding new improved text is next level to build on top
of this. That work could include improving this paragraph.

Regards,
Andreas Henriksson