Re: Future of update-rc.d in wheezy+1
Roger Leigh <email@example.com> writes:
> Hi folks,
> I'd just like to briefly discuss potential plans for update-rc.d
> in wheezy+1, and how this might impact on file-rc and sysv-rc.
> sysv-rc has defaulted to using LSB header dependencies and insserv
> for a few years now. The last few releases require you to enable
> insserv to upgrade, and the pending upload just does this
> automatically. The result is that all wheezy users of sysv-rc
> will be using dependency-based boot.
> This means that the runlevels and sequence numbers passed as
> arguments to update-rc.d will never be used; they will just get
> silently discarded. The main problem as I see it is that these
> numbers are going to bitrot badly--they aren't being tested, while
> the dependency information in the header is being used by everyone.
> I'd like to suggest that we do the following in sysv-rc update-rc.d:
> - wheezy: silently drop start|stop sequence numbers and runlevels
> (this is already the case when using insserv, and we can remove the
> non-insserv codepaths)
> - wheezy+1: warn if these options are used
> - wheezy+2: remove support for the options and error out if used
> And additionally, to add lintian warnings for use of these options,
> including when using dh_installinit.
> The main problem that I can see is file-rc is currently still
> dependent upon the sequence numbers and runlevel information. Would
> it be possible for file-rc to also add support for dependencies?
> Given that the static boot ordering is quite dead at this point, it
> would be very helpful to know what's possible here. Could it use
> insserv to do the dependency graph and then just consume the
> makefile-style dependency list?
You say the numbers are going to bitrot, which I totaly agree. But that
could be prevented.
The numbers specified for update-rc.d must be well ordered according to
the dependencies specified in the LSB headers. That means that that
update-rc.d could keep a record of the numbers specified and check that
the numbers are valid even though sysv-rc/insserv then ignore them.
This check could also be done as archive wide check using piuparts or
something. Doesn't have to be done on every users systems.