jwrober at linuxfromscratch.org
Fri Jul 16 08:55:07 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.
>> 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.
>>> 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.
> 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 :-) )
> 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.
More information about the lfs-dev