Bootscript Future

James Robertson jwrober at
Thu Jul 15 06:15:45 PDT 2004

Nathan Coulson wrote:
> I noticed there have been some complaints about the current status of the
> lfs-bootscripts with their position within the LFS Project, and I wish to
> (hopefully) find out what we [The Bootscript Team (whoever's left)] can do
> to help.
> First off, I dont believe the scripts should be able to handle any
> situation on their own, but can be extended to handle any situation.  To
> that end, I am attempting not to fix user mistakes in customization, or
> automatic detection of what should be done.  In the event I do correct a
> user, I attempt to provide a warning message to the user.

I read the wiki page and I agree with this.  That would dumb down the 
user responsibility way too much.

> Next, I am going to break up the scripts into their subsections, to give a
> more individualized view [giving the users on this list a chance to
> comment on key decisions].
> a) I layed down a base set of policies which the scripts "should" follow
> at
> [that reminds me, I should wipe the 2.1 migration text now that it's in
> the book].
> b) Udev and Hotplug: I am not entirely satisfied with these scripts as of
> yet, but they do work fine.   (Please note that the hotplug script is not
> installed by default)

How are you going to handle the split (or difference) between the three 
tiers of development in your scripts?  For example, today stable has one 
version of the scripts - good.  Then testing and unstable seem to be 
sharing a version that includes both udev and hotplug, but both of those 
things are not in both places.

> c) modules: This script provides automatic loading of modules at boottime.
>  I would prefer alternatives to using this script, but I do not have any
> better ideas at this current time.  Other then that, it is a great script

I don't do modules, so I can't properly comment.

> d) Networking: I am farely happy with the current state of the networking
> system.  You can configure it through user customized files, which are run
> by a script named in the SERVICE= line.  With the move to directory based
> configuration, we can return to configuration by the name of the internet
> interface, fixing a few scripts in BLFS.  Easly extended onto by adding
> new user created service scripts [or blfs].

I like the new network stuff as well.  I need to learn iproute2 now. 
This kind of stuff probably needs to either end up in the book or the 
book needs to provide pointers to documentation on iproute2.  ifconfig 
has been around for a long time and so a lot of folks will not know 
about this different package.

> e) functions: bunch of functions used by all the scripts.  It does seem a
> bit overbearing to new users at this time.

I see this as an excellent educational opportunity.  I think having the 
entire scripts in the book is overkill, but dedicating a chapter or at 
least a few pages in the book on the subject of the scripts would be 
great.  The package needs good documentation (as all good packages need 
documentation), so why can't the LFS book provide the medium? 
chapter07/usage.html is a small start.  We could go into more depth though.

> f) createfiles: when I had /tmp erased at shutdown, I wanted a way to make
> sure that files/directories could be created at startup [Nice way to
> populate /tmp, or /var/run].  Zack Winkles built this for me.  Since this
> exists, it will help simplify some configuration in the BLFS book, or
> hints.

I don;t see any issues here.

Overall, I like the package.  I know some think that we should tell the 
user how to write their own.  That could be a book in itself.  Scripting 
is not simple, it takes skill - especially the stuff you guys are doing. 
  Requiring the user to type in the scripts by hand would be very error 
prone and could easily increase the traffic on -support.  Requiring the 
user to write their own from scratch would significantly raise the bar 
to entry for the book IMO.  Even with direction, we would have to do a 
lot of writing to do that.  This would also significantly increase the 
traffic on -support.  I still think we can come to a compromise for both 
camps here.  Have the scripts provide base functionality for the book 
like you have done.  If you provide more in the package than the book 
requires, then have the Makefile provide the targets that we need to 
only install the bare bones stuff.  Put in the book and/or README that 
there is more if you want/need it or just ant to try it out.  The book 
would not go into any more detail about that, it would be up to the 
reader to explore.  The scripts are customizable and with good 
documentation provide a means of education and the ability to 
add/remove/hack/whatever to each user's content.  I change them some, 
for my own needs.  It took me awhile to read through the code to figure 
out what they were was doing, but I got it eventually.  There is still a 
lot I don't get, but hopefully the next book can alleviate that issue.


More information about the lfs-dev mailing list