Bootscript Future

Nathan Coulson conathan at conet.dyndns.org
Fri Jul 16 12:35:06 PDT 2004


> Nathan Coulson wrote:
>  > James Robertson wrote:
>>>
>>> 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.
>>
>> Well, right now we have a contrib directory for additional scripts
>> submitted by users, that could be of use to the end user, but not
>> installed by default [Hotplug used to be there, then I threw it in
>> the main scripts when it "appeared" that it would be going back to
>> stable] (make install-hotplug still installs it)
>>
>> In the past, Zack started making alternative sets of bootscripts, but
>> I got them synced up via use of the contrib dir.  I dont really want
>> to be supporting 2 simular yet different sets of bootscripts if there
>> is no point.
>
> OK, I forgot about that.  That sounds good to me.  I admit I have not
> read the README, so I don't know if you put notes in there or not about
> contrib.  We could probably do the same in the book.  One or two
> sentences won't hurt.

no contrib stuff [I think I even forgot to mention hotplug, when I moved
it back into the bulk, whoops].  but those things are usually well
commented.

>>> 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.
>>
>> in the past, it appears the LFS Project prefers to point to
>> documentation over including it themselves.  (although I dont think
>> there is a suitable location for such a link as of yet).  In the
>> other packages included in the book, we usually dont say how they
>> work and therefore it'll have to be mentioned in relationship to the
>> bootscript configuration themselves if/when we provide more
>> information.
>
> That is true.  Archaic made a point about how we handle other packages
> (listing the programs and then being able to use man [program]).  Since
> the bootscripts don't provide man pages (thank goodness!) having a wiki
> page or just putting lots of comments in the code could probably
> suffice.  Actually, now on second thought, I think comments in the code
> would be better.  Put the list of scripts installed on the book page
> just like we do for every other package and then tell them to go
> digging.  I have learned a lot, just by digging in the script code.
>
> I don't see the LFS point to that many external docs.  Most of the link
> outside are to hints or BLFS pages.  That could be considered "external"
> to some. I see that as maybe not mainstreamed into the book, but not
> really external as it has remained in the project's hierarchy.  I know
> others may disagree.  I consider external to be like that iproute doc
> link you provided.  We don't have very many of those in the book.  This
> topic could probably warrant a whole 'nother conversation.
>
>> (Currently I do not decide what documentation goes into the book, and
>>  therefore the above will have no impact on what actually happens in
>> the book.  I am just basing it on statistical information I have
>> observed over the last few years, and what may happen because of our
>> current policies).
>>
>> BTW, here's something I've been looking through lately
>> http://www.linuxgrill.com/iproute2-toc.html, perhaps it'll help out
>> whoever reads this email.
>
> That is nice.  Matt -- is this something we can add to the book?  This,
> of course, would follow from a policy decision yet to be determined maybe.

yknow, I could stick it into the ipv4-static script, as well as the
ipv4-static-route script.  [the URL that is].

>>>> 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.
>>
>> Well other then that README file I was working on, and the comments
>> within the scripts, we really dont have any further documentation.  I
>> would love to see a page or two on configuring some things within the
>> bootscripts, so users can do what they like with their system.  (At
>> this particular time, I dont have the time to do this myself)
>>
>> I think Nick may be writing something about them, but not sure what
>> his plans were. (sorry nick, if this was supose to wait)
>
> I also think that a page or two talking about the scripts would be good,
> or if that is not decided as something to go into the book, then the
> README could be pointed to.
>
>>>> 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.
>>
>> It is probably true, that people writing their own scripts would add
>> alot of complexity to LFS, and increase our lfs-support problems.
>>
>> What kind of changes have you made?  I unfortunately do not really
>> know what people do with the LFS-bootscripts once they install them.
>> (I know some used the createfiles thing mentioned above to make /dev
>> entries for things that udev misses, and I wanted it there for
>> XFree86's /tmp/.ICE-unix. [since I put in the changes to wipe /tmp])
>
> Oh, my changes are real minor.  I was having trouble differentiating
> between INIT messages and messages that programs generate to the console
> from messages that the scripts were generating, so I just edited the
> script files to add a space, an asterisk and then another space in front
> of most of the echo commands.  This is simply a personal thing.  If you
> like the idea, then go for it.  I honestly stole the idea from Gentoo's
> scripts.  I also changed the functions file to move the [  OK  ] deals
> to push right up to the far right edge of the screen.  Again, my taste
> only.  Other than that, I wrote my own console script from the template
> you provided in 2.0.5 before I figured out you had one in a later
> version of the scripts.  I like yours better.

actually, Alexander made the console file.  I think I'll leave text output
as is for now [in the future, I want to add logging messages, so people
know what their system is doing on bootup.  As the text is currently
formatted, this is not a easy procedure]

>> I do not believe much can be done before the LFS 6.0 release, unless
>> we had more volunteers familiar with the bootscripts able to write
>> some nice documentation on how to use some of the options, or to
>> document how the functions in /etc/rc.d/init.d/functions work.
>
> Oh, I think we can probably come up with something before 6.0.  Even if
> it is just commenting the crud out of the scripts, updating the install
> page with some more info, and finishing the README.  That will be a good
> start IMO.  I know I would like to see more comments in functions.  That
> sucker is complex (well, at least to me it is :-) )

I felt the same way at first [wonder why I dont think so anymore...]. 
been almost scared to touch it because of that, but I think I know how it
works.

>> BTW, if you notice things that do seem overly complex, just drop me a
>>  line.  If the scripts themselves are their documentation, it helps
>> when they're readable.
>>
>
> James


Thanks for your input, I'll add it to my todo list.



More information about the lfs-dev mailing list