Moving to new format?

Bill's LFS Login lfsbill at
Sat Jan 18 15:03:07 PST 2003

On Sat, 18 Jan 2003, Bruce Dubbs wrote:

> Billy O'Connor wrote:
> >tushar at (Tushar Teredesai) writes:
> >>Hi:
> >>
> >>Will the BLFS book be moving to the newer format that the LFS book
> >><snip>

> >I don't feel this would be a good format for BLFS.  BLFS installs
> >packages that are quite a bit more complicated than the ones in the
> >LFS book.  Some of the more complicated packages would have build
> >commands farther apart than I'd like to see them.
> >
> I agree.  BLFS should keep the format it is using.  Man y of the
> libraries are a simple configure && make && make install, but there are
> other packages that are quite complicated.  I feel the BLFS is part
> learning, part HOWTO, and part reference.  LFS is going to primarily
> learning and I think that is very appropriate.  When you graduate to
> BLFS, the explainations should be less detailed at the basic level and
> concentrate on more advanced issues.
>   -- Bruce

Me too! From a user's view (ignoring benefits/costs to (B)LFS editors
and testers), significant differences include:

    LFS  : front-to-back, sequential process of the book, little
           decision-making required, "cockpit workload" is manageable.
    BLFS : non-sequential, user determines packages needed based on
           dependencies listed and the "target" packages, much more
           decision-making required, can get quite complex, "cockpit
           workload" can be difficult to manage effectively.

    LFS  : Relatively few packages, (apparently) better tested by the
           package maintainers (I know this could be argued, but let's
           not and just say that we did) means that the actual number
           and frequency of change is "reasonable".
    BLFS : *Lots* of packages, (apparently) less-well tested by the
           package maintainers, *many* more packages resulting in a much
           *higher* frequency of change. Everyhting BLFS can do to
           avoid/reduce page turning, URL processing, syntax errors
           and command omission/corruption is highly desirable.

    LFS  : Gcc/glibc type changes propagate through a well-known and
           finite set of dependent packages. Testing, correction and
           book update tends to progress more predictably.
    BLFS : Gcc/glibc type changes propagate through a partially known
           and (seems like) infinite set of packages that have not yet
           adapted to ANSI C and/or the new ABI interface and have
           non-standard make/config "issues". Then there is the effect
           of junk like "hidden" symbol dependencies exposed by
           unilateral gcc/glibc changes.

In sum, from my view, what is perfectly suitable for the LFS book would
be a user's nightmare for the BLFS book.

Of course, the editor's load needs to be also considered, but I can not
rationally address those issues.

Bill Maltby
lfsbill at

Unsubscribe: send email to listar at
and put 'unsubscribe blfs-dev' in the subject header of the message

More information about the blfs-dev mailing list