Bug#591791: extend init.d policy to permit upstart jobs and describe their use
On Wed, Jan 12, 2011 at 6:38 PM, Kurt Roeckx <email@example.com> wrote:
> On Wed, Jan 12, 2011 at 12:50:21AM -0600, Steve Langasek wrote:
>> On Mon, Jan 10, 2011 at 09:17:33PM +0100, Kurt Roeckx wrote:
>> > A lot of the scripts currently in /etc/rcS.d/ come from the
>> > initscripts package. Is the alternative supposed to implement
>> > all the functionality by those scripts? Or do we expect them
>> > to run the scripts from /etc/rcS.d/ as 9.3.4. seems to suggest?
>> Well, the initscripts package in Ubuntu does provide one script that's run
>> in /etc/rcS.d (urandom) and several other scripts that are run in other
>> runlevels (some in 0/6; some in 1; some in 2 3 4 5). But there's definitely
>> a delta in the initscripts package when used with sysvinit vs. upstart. I'm
>> not sure if this is something that needs to be specified in policy though,
>> as opposed to just being worked through in the implementation.
> I'm fine with leaving it up to the implementation on exactly which
> part it does itself and which it takes from initscripts or
> somewhere else. But what I do expect is that in the end the system
> is in the same state, and I guess I sometimes think too much about
> the details of how this is supposed to happen. Does Ubuntu just
> ship a package with less scripts in initscripts, or does upstart
> lists somewhere which ones it wants or doesn't want?
The Ubuntu initscripts package contains fewer and modified scripts
(the plan is for it to not exist at all), since the conversion has
been made for those tasks to be performed by Upstart jobs.
(Systemd largely has support for those tasks built-in)
>> > What should packages do that want to have their script run
>> > at that time? For sysvinit scripts this is calling update-rc.d
>> > with S as the runlevel. I don't know if the alternatives
>> > support something like a runlevel, and which they support.
>> I think this is covered already by requiring alternative init
>> implementations to support running sysvinit scripts - rcS.d is definitely
>> part of this, just as rc[0-6].d are. Do you think we should be more
>> explicit about the supported runlevels? (It's awkward to talk about
>> rc[0-6].d directly, precisely because this is an internal detail of sysv-rc
>> vs. file-rc)
> So you're saying that rcS.d and rc[0-6].d will keep existing? I assumed
> it wouldn't exist anymore, or atleast not for all cases, and that
> update-rc.d would do something with it that's specific to the init
I would have thought that rcS.d/rc[0-6].d are not compulsory parts, as
replacement init systems may simply read the LSB headers from the top
and allow them to be overridden in some way.
To me, the update-rc.d/chkconfig style standard is the right one.