Re: Transition of initscripts to new order / sequence number
On Sun, 22 Mar 2009, Steve Langasek wrote:
> On Sun, Mar 22, 2009 at 09:16:31AM +0100, Jakub Wilk wrote:
> >> It seems to me that it would be a lot less effort to fix this by removing
> >> file-rc in Debian, which has only a handful (137) of popcon reports. Even
> >> if we take into consideration that popcon isn't a good source of absolute
> >> numbers, this comes out to .2% of popcon reports that we're spending this
> >> effort on, and for what benefit?
> > Benefit of having an abstraction layer.
>
> That's not a benefit, that's a burden. You don't abstract things that you
> don't *need* to have abstracted.
Only, in this case, we need it abstracted (which it already is), and we need
it to _remain_ abstracted.
Otherwise, we will have massive pains to switch initsystems (as in: it will
be either completely impossible, or it will take two or three stable
releases to do it). It was trouble enough to implement invoke-rc.d.
> > - They never had to fiddle with runlevels, so they don't known what
> > a nuisance it is with sysv-rc.
>
> As far as I'm concerned, that's an argument for improving the tools for
> managing runlevels via sysv-rc, not for changing the update-rc.d API.
The update-rc.d API is incomplete. It really needs to be extended, and
that's what people are doing. update-rc.d is a maintainer script API (if
the local admin wants to use it directly, that's his problem). This has
_nothing_ to do with end-user tools for sysv-rc.
No regular package maintainer script has _any_ business dealing with sysv-rc
tools (exceptions are other initscript subsystem packages, sysv-rc packages,
etc). They need to do it over the abstraction layer, so that they will work
with different initscript systems.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: