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
