How packages should supply dependency information
Thomas Hood
jdthood at yahoo.co.uk
Mon Nov 7 15:31:27 UTC 2005
Initscripts have certain dependencies. Currently information about these
dependencies is supplied by packages in a very inconvenient form: the
package postinst runs update-rc.d with some arguments. update-rc.d uses
this information to update symlinks or files and then discards it,
whereas the information really should be kept so that it can be used to
implement "restore factory defaults" functions in runlevel editors.
Recently Petter Reinholdtsen began asking many package maintainers to add
dependency information to initscripts in comment headers, formatted
according to the LSB spec. See bugs ##32467[19], 330227, 330230, 332848,
332857, 33530[589], 335311, 33532[023], 33534[378], 33535[09], 33538[89],
337053, 337639, 33764[045]. If there was a discussion preceding this
mass bug filing then I ask someone to provide me the URL so that I can
read up.
I think that "magic comments" are almost always an indication of poor
design. I have another suggestion which I shall now describe.
The idea is to provide dependency information in files, and to make use
of the existing update-rc.d interface.
Phase 1
-------
Enhance update-rc.d so that dependency information can be given to it
via a file. The file would have the standard name
/usr/share/init/deps/<package> overridable using a command line option.
The file would have the following format:
Provides: boot_facility_1 [ boot_facility_2 ...]
Required-Start: boot_facility_1 [ boot_facility_2 ...]
Required-Stop: boot_facility_1 [ boot_facility_2 ...]
Should-Start: boot_facility_1 [ boot_facility_2 ...]
Should-Stop: boot_facility_1 [ boot_facility_2 ...]
Default-Start: run_level_1 [ run_level_2 ...]
Default-Stop: run_level_1 [ run_level_2 ...]
Short-Description: short_description
Description: multiline_description
(I.e., LSB format: the above comes from the LSB spec:
http://refspecs.freestandards.org/LSB_2.1.0/LSB-generic/LSB-generic/initscrcomconv.html.)
Options specified on the command line would override any in the file,
where 'start' corresponds to 'Default-Start:' and 'stop' to 'Default-Stop:'.
Phase 2
-------
Modify dh_installinit so that
dh_installinit -- start 30 S . stop 70 0 6 .
which currently puts:
if [ -x "/etc/init.d/alsa-utils" ]; then
update-rc.d NAME start 30 S . stop 70 0 6 . >/dev/null || exit 0
fi
in NAME.postinst, instead copies debian/NAME.init.deps to the correct
location, if present, otherwise creates a deps file on the basis of the
information on the command line, and puts:
if [ -x "/etc/init.d/NAME" ]; then
update-rc.d NAME >/dev/null || exit 0
fi
in NAME.postinst. (Again, this assumes that the name of the initscript
is the same as the name of the file.)
Now we have the dependency information in files. Yay!
Phase 3
-------
Ask package maintainers to add init deps files. These should contain
the Default-Start and Default-Stop specifications, as before, but can
also contain valid Required-Start and Required-Stop specs.
Phase 4
-------
At this point it become possible for init systems to take advantage of
dependency information that package maintainers have made available.
The rule would be that the init system has to satisfy Required-* if
these are present in the deps file; otherwise the system has to satisfy
Default-*. The more Required-* specs, the more freedom the init system
has to do things in parallel.
By following these steps we can ensure a smoothe transition from the
current system to a dependency-based system.
Comments and suggestions more than welcome.
--
Thomas Hood
More information about the initscripts-ng-devel
mailing list