What is LFS anyway?
ken at kenmoffat.uklinux.net
Mon May 10 04:07:27 PDT 2004
On Mon, 10 May 2004, Jon wrote:
> Joel Miller wrote:
> >As much as I always install a dhcp client on all the machines I build,
> if we stick dhcp
> >into the base LFS, whose instructions are to be followed in order and
> none are to be
> >skipped, what dhcp client will go into the book. Therein lies the
> problem as I see it. I >happen to use and like dhclient. Other people I
> know use dhcpcd. Yet others I know use a >program called pump which I
> have no knowledge of. The choise of client should be up to
> >the user. Is it enough that perhaps we point them to the dhcp section
> in BLFS?
> Why can there not be an option as to which to install? When reading
> from top to bottom, you can say "At this point you have a choice...".
> If someone can build LFS, then I am sure that they can follow the part
> where you skip section X.y.B and X.y.C if you did X.y.A
Yay! A chance to get lilo back into the book! As I've said before,
I'm all in favour of (at a minimum) arch-specific bootloaders (grub,
yaboot, various lesser-used things) and of building the bootloader at
the end of the book, but recognising that people are building LFS on
other architectures adds more overhead for the editors.
The freedom to use or omit functionality, and to choose which competing
package to use, is a natural part of BLFS. We assume our users have
enough experience to work out what they need to do after LFS. If we're
going to start merging BLFS *packages* into LFS, things will get very
messy for the editors of both books. [Note: I'm not arguing against
moving inputrc and other configuration into LFS]
Notice that as the community grows, the number of LFS "product lines"
is growing towards the debian model. That isn't a problem, but it means
the expertise will be spread more narrowly. Adding *optional* things
into LFS is just going to make it harder to test a release.
das eine Mal als Tragödie, das andere Mal als Farce
More information about the lfs-dev