Bug#361137: [PROPOSAL] Make use of invoke-rc.d, if available, mandatory
Package: debian-policy
Severity: wishlist
Given that the initial reactions to this were uniformly positive, I'll
need to actually start following procedure and use the BTS.
The formal proposal is to change 9.3.3.2 ("Running initscripts"), second
paragraph, from this:
The use of invoke-rc.d to invoke the /etc/init.d/* initscripts
is strongly recommended[51], instead of calling them directly.
to this:
The use of invoke-rc.d to invoke the /etc/init.d/* initscripts
is mandatory if it is installed.
Because invoke-rc.d is in a package (sysv-rc or file-rc) that an
essential package depends on, it is guaranteed that invoke-rc.d is
always on the system. In principle, we could then strike the four last
words of the proposed paragraph, which would simplify things for
packages. I am unsure of whether we should make invoke-rc.d's
essentialness more explicit in that case.
ma, 2006-04-03 kello 00:38 +0300, Lars Wirzenius kirjoitti:
> Current policy states in section 9.3.3.2 ("Running initscripts") the
> following: "The use of invoke-rc.d to invoke the /etc/init.d/*
> initscripts is strongly recommended[51], instead of calling them
> directly."
>
> Footnote 51 further says: "In the future, the use of invoke-rc.d to
> invoke initscripts shall be made mandatory. Maintainers are advised to
> switch to invoke-rc.d as soon as possible."
>
> I propose that the future has arrived.
>
> I ran the attached script on all binary packages in sid/main/i386, and
> it reported 134 packages that I then analyzed manually. There were only
> two false positives (both mentioned how to run their init.d script in a
> message to the user, but didn't run it themselves). All other reported
> packages were true positives. I have attached the list as well.
>
> Almost all of the packages in the list are either dict-* packages
> (seemingly from the same template), have code from an old debhelper
> version (so a rebuild might suffice), or are otherwise pretty easy to
> fix. Even though the number of packages are fairly large, it is my
> opinion that it should be possible to keep the transition period quite
> short, weeks at most, and I'm willing to put some time into it.
>
> See also bug #353659 against lintian to add a check for this.
>
> I would like to see this policy change happen in time for all packages
> to be updated in etch. This would mean that sysadmins can, finally, rely
> on policy-rc.d working reliably. Also it means that it would be easier
> to build chroots, and not have to worry about services and daemons being
> started inside them unnecessarily.
>
> I realize that my script doesn't find all problematic packages. It is
> meant as a quick estimate. For proper testing, I have recently
> implemented changes into piuparts that should make it possible to find
> all problematic packages: in my development version /proc now gets
> mounted (ergo, start-stop-daemon works), and after packages have been
> installed, lsof checks that no processes run inside the chroot. This
> will, I hope, catch packages that don't use invoke-rc.d when they
> should.
>
> Are there any objections to this proposed change? (If there are none
> within a few days, I'll file the appropriate bug against debian-policy.)
--
Just GNU it!
Reply to: