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
>>> 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
> 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
>> 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.
Thanks for your input, I'll add it to my todo list.
More information about the lfs-dev