> 1. Give up. Point people to cblfs, or change the blfs wiki > so that anyone can post again. [ not my preferred solution, > but
Cblfs does have its benefits, it feels more up-to-date but at the expense of a "known good" package set at any given point in time. When building LFS/BLFS I prefer BLFS packages if they exist since they are much more hammered on but do find myself checking CBLFS if there is no corresponding set of instructions in BLFS. > 3. Follow LFS-svn. Inevitably, this means some packages > are out of date. In some ways, that would be "going back > to our roots" in the early days of BLFS. I think it helps to have perspective on 2 types of target audiences for the books: 1. Stable users Should have a book that is validated as much as possible, testing a stable BLFS against a stable LFS. Stable builds, IMO, are extremely critical to the users being introduced to a system they have confidence in. 2. Testing users If a user is ready for this then they know they are dealing with issues. It's ok if things are constantly broken. I know I'm not a dev in here but I just thought it would be helpful to get an alternate perspective. Most of the bugfixes etc. do occur in "testing" versions but it's not worth it to scare new users away by never officially stablizing. A new user that is introduced to LFS now would have to be directed to use LFS-6.2/BLFS-6.2 in order to show them what is possible. Thanks, Craig Jackson [email protected] 253-459-5384 cell -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
