Kernel page, once again

James Robertson jwrober at linuxfromscratch.org
Tue Jun 15 20:02:51 PDT 2004


Jeroen Coumans wrote:

> Summary of your long post (please correct me if I misrepresent you):
> 1. we should include configuration and documentation for all possible 
> combinations of packages which a user can optionally install. This is 
> because the current docs about hotplug/udev are insufficient, and there 
> are too many problems a user can run into.
> 2. if a package is optional and has alternatives, we should include at 
> least one alternative.
> 
> This goes IMHO exactly against the currently default principle that we 
> should provide instructions and support for one default choice, but 
> point out alternatives. Arguments:
> * including more then one alternative means you have to include all 
> alternatives
> * there is no educational benefit for providing more then one package 
> which serves the same function
> * we try to keep the number of packages in the book down because LFS 
> does not try to be everything to all people
> * we have to assume the reader follows the book, because it would 
> require not only a lot more support issues, but also testing and QA 
> issues if we account for every deviation.
> 
> Furthermore, in my POV, optional only means that the package is not 
> required for a fully functional LFS system, not that the book provides 
> instructions in case you leave it out. Perhaps we should declare all 
> packages mandatory...
> 
> Lastly, your points that udev's documentation is incomplete and it has a 
> lot of possible traps are only arguments to reconsider the decision to 
> include it in the book, not a reason to expand the book just because the 
> package is not ready yet! I have repeatedly stated that I didn't 
> consider udev ready for prime time (bleeding edge); seems that you just 
> confirmed my opinion.
> 

I have to agree completely.  Since I have joined the project and seen 
the progress we have made, we still work towards these principals.  Some 
of this kind of stuff can certainly be played out in the unstable branch 
(that is what it is for after all).  We still need to *pick a best path* 
for the stable branch and releases.  We should pick well defined 
packages and configurations that work for most folks.  We pick the EXT3 
filesystem for example because of it's journaling capabilities and as a 
small extension to EXT2, is very stable.  That is not to say that a 
seasoned LFS'er may prefer reiserfs or xfs, or whatever.  That is their 
choice.  The book will still use EXT3.  This is but one small example. 
Everything else still follows, though IMVHO.  Jeroen is very correct 
here.  Deviation by choice only increases the burden of test and QA.  I 
think the hint thing we have going now is great.  This provides a way to 
provide a means of deviation *at your own risk*, while still keeping the 
one path only method in the book.

Note to Matt - can we make sure that as part of an impending release of 
stable and probably test that we ensure that all hints/external docs we 
point to are current or at least actively maintained?  This will help 
with part of the issue, I think.

My $0.02
James

-- 
James Robertson -- jwrober at linuxfromscratch dot org
Reg. Linux User -- #160424 -- http://counter.li.org
Reg. LFS User   -- #6981   -- http://www.linuxfromscratch.org
LFS Bugzilla Maintainer    -- http://{blfs-}bugs.linuxfromscratch.org



More information about the lfs-dev mailing list