Hi, Steve Langasek wrote: > On Sat, Mar 05, 2011 at 02:19:12AM -0600, Jonathan Nieder wrote:
>> 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 Exactly. That makes this old suggestion of mine a very bad idea, and I'm glad you caught it back then, too. ;-) [...] >> 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? [...] > for admin invocations, a frontend > like the 'service' command is more user-friendly anyway. I don't agree, but I agree that it's not worth the fuss to teach /etc/init.d/foo to pass on requests and handle all edge cases appropriately, so this is academic. [...] >> . 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. I guess so. (ii) is already implied by "don't be buggy". (i) is probably worth spelling out, though --- I'll look at your patch to see if it does so. In an ideal world, (i) would be enough [since it determines the behavior] and packagers could experiment and refer to each init system's interface documentation [e.g. manpages] for details, but I understand that documenting details on implementation strategy in one place can be useful for making the result easy to understand. Thanks again for your work on this! Jonathan -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111018052218.gb12...@elie.hsd1.il.comcast.net
