LFS-6.5-RC1 released

Craig Jackson craigmjackson at gmail.com
Mon Jul 20 15:13:24 PDT 2009


> 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
craigmjackson at gmail.com
253-459-5384 cell



More information about the blfs-dev mailing list