Bug#835520: [PATCH 00/11] Trim obsolete/harmful info about init integration
Hello everyone,
Thanks for all feedback and reviews.
Extra thanks to Martins very in-depth review. Even going over the commit
messages (and not just the actual policy changes)! :)
I've updated my patchset and will post a v2 soon, incorporating
all of Martins (and others) suggestion except the below one....
(Please feel free to make sure I didn't misinterpret or screw
something up while doing so.)
On Mon, Dec 12, 2016 at 03:40:36PM +0100, Martin Pitt wrote:
> Hello Andreas,
[...]
> Andreas Henriksson [2016-12-06 15:07 +0100]:
> > [Replace init example by refering to dh-make]
> > <p>
> > - An example on which you can base your
> > - <file>/etc/init.d</file> scripts is found in
> > - <file>/etc/init.d/skeleton</file>.
> > + An example on which you can base your init integration on
> > + is available in the output generated by <prgn>dh_make</prgn>.
> > </p>
>
> We should absolutely drop the reference to /etc/init.d/skeleton as it
> is not even present on a default install any more (it's Priority:
> optional) and has several problems. I'm not familiar with dh-make, so
> I can't second this as-is in good faith, but I agree with Andrey that
> introducing this into the policy feels undesirable.
>
> So as long as we don't have anyone wanting to fix sysvinit for this,
> I'd rather just drop this paragraph entirely.
... instead I've replaced my "patch 10" with Felipes suggestion
which probably also is in line with what Andrey was thinking.
Possibly we should just drop "patch 10" entirely for this round!
It's not critical and we could discuss how to best approach it
separately and reach consensus on it separately.
(I don't have any personal objections against dropping the reference
to the current skeleton file as I don't think it's a good example
since it has unresolved outstanding issues. That it's not part
of the default install anymore is less of a concern for me, and
I think that could simply be adressed by adding a note of
the package where the file can be found in.)
I'm hoping it's time for Policy Editors to take it from here.
In my view the change covers what Policy Change Process[1] says
regarding being technically correct, not disruptive (keeping the
policy unaltered would be much more disruptive IMO), reviewed including
by domain experts (like Felipe and Martin), have rough consensus (as
there's been no major objections and mostly, possibly somewhat informal,
seconds) and hopefully no maintainers will be (negatively) affected
by the change.
FYI, the changes in Dons latest upload doesn't seem to have been merged
back into the dbnpolicy git repo. Don told me his changes are available
in a branch at:
http://git.donarmstrong.com/debian/debian-policy.git
I've tested to make sure my patches rebases/applies cleanly on top
of his.
Is there anything else I can do on my side?
(Seeing progress being made here would motivate me to try to help with
other outstanding policy bug reports.)
Regards,
Andreas Henriksson
[1]: https://wiki.debian.org/PolicyChangesProcess
Reply to: