Sean Whitton <spwhit...@spwhitton.name> writes: > On Thu 26 Sep 2019 at 09:01AM +02, Ansgar Burchardt wrote:
>> Control: reassign -1 debian-policy >> >> The section on initscripts has too much implementation details about >> /etc/rcn.d; these are better explained by external documentation. > Are you saying that they are *currently* better explained by actually > existing external documentation, or that it would be better to have them > explained by external documentation instead of the Policy Manual? If > the former, could you point to that documentation, please? I agree with removing the discussion of the symlink forest and how it is managed. We require use of update-rc.d and prohibits mucking about with the symlinks. Given that, I think the symlink forest is an implementation detail of sysv-rc and we should remove the detailed documentation of it from Policy and keep only the requirement to use update-rc.d and the details required to invoke it correctly (which includes some discussion of run levels). I'm hesitant to remove all discussion of run levels because package maintainers are still responsible for choosing a run level at which to start their service and providing that run level as an argument to update-rc.d. I think Policy should include enough details to allow package maintainers to make that decision. That said, the current text doesn't include any useful advice, so I'm okay with removing what discussion there currently is and then reintroducing some better documentation later when someone gets a chance to write it. >> Also the rationale for why `DISABLED=yes` (or similar) fits better >> into a footnote than the main text (IMHO). > I'm inclined to agree with you, but since Russ is keen to reduce the > number of footnotes in Policy, it would be good to hear from him here. I don't like footnotes; if something is important enough to say, I think it's usually important enough to put into the main text without making people click or jump around to find it. But I think the current paragraph in Policy is poorly worded and not as general or as straightforward as it could be, and it's weirdly out of place in the update-rc.d section. How about, rather than moving it to a footnote, rephrasing it as follows? Except when the package has been removed but not purged, as described above, the ``/etc/init.d`` script should not decide whether or not to start the daemon based on configuration settings (such as settings in ``/etc/default``) or silently exit successfully when the daemon could not be started. This causes inconsistent and confusing behavior such as ``service <package> start`` returning success but not starting the service; services with a dependency on this service starting even though the service isn’t running; and init system status commands claiming that the service was started. If the ``/etc/init.d`` script is invoked with the ``start`` or ``restart`` arguments and the service could not or should not be started, it should produce an appropriate error message and exit with a non-zero status. and then moving this whole paragraph into 9.3.2, probably as the second-to-last paragraph? -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>