Hi Jonathan, On Sat, Mar 05, 2011 at 02:19:12AM -0600, Jonathan Nieder wrote: > > + tasks at boot time. However, any package integrating with other > > + init systems must also be backwards-compatible with > > + <package>sysvinit</package> by providing a SysV-style init script > > + with the same name as and equivalent functionality to any > > + init-specific job, as this is the only start-up configuration > > + method guaranteed to be supported by all init implementations. An > > + exception to this rule is scripts or jobs provided by the init > > + implementation itself; such jobs may be required for an > > + implementation-specific equivalent of the <file>/etc/rcS.d/</file> > > + scripts and may not have a one-to-one correspondence with the init > > + scripts. > Maybe policy could allow (but discourage) packages that only support > some non-Sys-V init system as long as they include a dependency > indicating so? I don't think that's something that should be allowed. You can only have one init system installed at a time; and all of the interesting alternatives to sysvinit are currently Linux-only. So if maintainers start choosing to only support one of the alternatives, they will quickly fragment the distribution (because not all maintainers are going to choose the *same* alternative), and they will render their packages unusable on our non-Linux ports. The only reason for any package to provide only an upstart job, or only a systemd config, is if it's a cooperating package providing part of the base boot sequence for that init system. (E.g., mountall for upstart.) > One of the advantages of upstart and its kin is the simpler > configuration, after all, so I can imagine some maintainers wanting to > take advantage of that and not having time to debug a standard init > script. The example that led me to mention this is Bug#422139; it is > not quite the same issue but is related. Having written many upstart jobs, I understand the appeal of not having to maintain a sysvinit script for backwards-compatibility. However, the slow movement of upstart in Debian so far, and this policy bug proposing rules for alternate init systems, are specifically about ensuring that we do *not* lose backwards-compatibility. Now, if someone were to write a tool to automatically translate an upstart job into an init script, that might be an interesting way to handle this; but most upstart jobs will be missing information about things like how to ask a daemon to create a pid file, or where the pid file will be stored, so the applications might still be limited. > As a naïve user, I'd prefer the SysV init scripts to pass on requests to > upstart when upstart is running; is that feasible? It would be feasible to pass requests to upstart, but it would be unnecessary. If the upstart job is properly declared, upstart will have already started it in the runlevel (or queued it for starting) before the init script ever has a chance to ask; and for admin invocations, a frontend like the 'service' command is more user-friendly anyway. > I suspect it would be best to make the language init system neutral, > and to say something to this effect: > . sysvinit scripts need to behave reasonably regardless of the init > system in use. So: > i. If an equivalent job file for another init system is present, the > sysvinit script will not be automatically invoked by that init > system when switching runlevels. In this case, when that init > system is in use, the sysvinit script (if invoked by hand, for > example) must either delegate requests to the init system or > error out without doing anything. Don't fight with init(8). > ii. Even if an equivalent job file for another init system is > available, the sysvinit script should behave as advertised (and > not be a no-op) when init is sysvinit. I agree that these are the relevant principles, but I think Policy should spell out exact requirements for each init system. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature