dj at linuxfromscratch.org
Sat Sep 1 00:54:05 PDT 2007
Dan Nicholson wrote:
> Now that 6.3 is finally done, I wanted to think about things that
> could be done for the 7.0 release. These are in addition to the normal
> updates/bug fixes/etc.
Like all ideas, but I have a feeling that we'll want to split the books
up when dragging in multi-lib setups.
> * LSB bootscripts - I'd like to shed the current custom bootscripts
> and move to the standardized LSB style. The advantages (to me) are
> standardization, removal of crufty custom functions and entry points
> in our current implementation, and managed service levels
> (dependencies in the script header mean you don't have to guess run
> The disadvantages are that all scripts need to be updated and
> install_initd still needs to be written (I have a shortcut bash
> implementation, but it doesn't implement everything).
I was working on a bash script for this, a partially complete
install_initd is in my home dir. For my own system, I was also going to
try to make the scripts run in parallel using a method that Jim Gifford
brought to us quite a while ago that utilizes the make utility.
>From that example, I now have a much easier idea for the rewrites and
may ditch the X-$distro-Default-* headers and make the numbering
completely dynamic with every installed script. As long as the
dependencies are correct, we would not have to worry about keeping a
numbered list at all. In addition, this concerning Richard's comments,
I've put the functions that determine the dependencies into a separate
initd-functions file so that it could be used for other sysinit types.
Of course, looking at runit and initng (you are still using runit
right?), the functions would be about as useless as the LSB headers, but
for the simpleinit variants (needs/provides init types) they can be
adapted easily. If you like the idea of upstart (I don't), Debian has
already done the legwork to use Suse's insserv with it. Unfortunately,
insserv lacks the ability to reorder the stop scripts. Debian has also
done some work with mininit, and both are 'ready for testing' over at
their SoC2006 project.
There is some good info in the archives there if you are curious about
some of the alternatives to svysvinit.
> DJ has a setup
> in contrib/lsb-v3 that's pretty solid and contains compatibility
> wrappers for all our current LFS functions.
No, actually they are not compatibility wrappers, but LFS specific
functions. They make use of LSB defined functions more compact by
getting rid of a lot of repetitive tasks. I just used familiar names
for the function names (unfortunately, killproc was taken) so that there
is less of a learning curve. However, while much easier, that 'learning
curve' goal went right out the window when I starting using the $MESSAGE
and $message variables.
Now, the current BLFS and hints project scripts can be used as is by
adding the current LFS functions file to /etc/init.d and creating an
'rc.d -> .' symlink in /etc. While the output won't be as pretty as the
default I chose for the LSB scripts, the legacy scripts will continue to
do their job during the transition time if we move in that direction.
-- DJ Lucas
More information about the lfs-dev