[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements



Steve Langasek wrote:

> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -7188,6 +7188,74 @@ Reloading <var>description</var> configuration...done.
[...]
> +          <p>
> +            Because packages shipping upstart jobs may be installed on
> +            systems that are not using upstart, maintainer scripts must
> +            still use the common <prgn>update-rc.d</prgn> and
> +            <prgn>invoke-rc.d</prgn> interfaces for configuring runlevels
> +            and for starting and stopping services.  These maintainer
> +            scripts must not call the <prgn>start</prgn>,
> +            <prgn>restart</prgn>, <prgn>reload</prgn>, or <prgn>stop</prgn>
> +            commands directly.

When I first read this, I wondered if in a postinst containing

	# Automatically added by dh_installinit
	if [ -x "/etc/init.d/vsftpd" ]; then
		update-rc.d vsftpd start 20 2 3 4 5 . stop 80 1 . >/dev/null
		invoke-rc.d vsftpd start || exit $?
	fi
	# End automatically added section

the "invoke-rc.d vsftpd start" line should be removed when I add an upstart
job.  Possible cause: the word "directly" is being asked to do too much.

Would the following be too strict?

	Maintainer scripts should not execute /etc/init.d/<package> scripts
	directly.

What init script actions would a maintainer script call without using
the invoke-rc.d wrapper?

The rest looks good to me, and I imagine the effect of some upstart
and systemd jobs integrated in the archive this way would be quite
nice.  (For example, maybe it would dispell some worries about the
possibility of event-based boot without commiting too early to a
particular init system.)

Thanks,
Jonathan



Reply to: