Moving to new format?
Bill's LFS Login
lfsbill at wlmcs.com
Sat Jan 18 15:03:07 PST 2003
On Sat, 18 Jan 2003, Bruce Dubbs wrote:
> Billy O'Connor wrote:
> >tushar at linuxfromscratch.org (Tushar Teredesai) writes:
> >>Will the BLFS book be moving to the newer format that the LFS book
> >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.
lfsbill at wlmcs.com
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe blfs-dev' in the subject header of the message
More information about the blfs-dev