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. > <snip>
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 > numbers). > > 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. http://www.ibm.com/developerworks/linux/library/l-boot.html >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. http://initscripts-ng.alioth.debian.org/soc2006-bootsystem/index.html 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 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
