Planning an overall direction for LFS

Dan Nicholson dbn.lists at
Fri Feb 29 07:46:41 PST 2008

On Fri, Feb 29, 2008 at 1:20 AM, Alan Lord <alanslists at> wrote:
> Bruce Dubbs wrote:
>  > Jeremy Huntwork wrote:
>  <snip />
> >> Merging the projects is a good idea, but I think, for the sake of
>  >> customization and flexibility, it will still be good to break down LFS
>  >> into 'modules' as Alan Lord suggested.
>  >
>  > I'm having a problem understanding this concept.  If one wants a web
>  > server, then you only need LFS and a few packages from BLFS.  If you
>  > want a workstation, then you need LFS and quite a few more packages from
>  > BLFS.  What's a "module" besides a list of packages for a particular
>  > application?  BLFS is set up to be able to jump around as necessary.  I
>  > must be missing something because I see a "module" as fundamentally LFS
>  > and a list of links in BLFS.
>  Bruce, my "modular idea was more about "training modules" rather than
>  sets of packages...
>  Here's the original suggestion I made:
>  ---
>  So perhaps the LFS project becomes some sort of "course" (and I use the
>  term loosely). The "modules" of which, could be something like:
>  * Learning the basics (Command Line, cmmi, security, toolchain, blah blah)
>  * Scripting/Automating (A subject about how LFS gets built, the tools,
>  the processes involved etc) [This is where PM would probably go too]
>  * Basic Useful Applications (A sort of mini BLFS where we get
>  networking, X and maybe Firefox/TB type apps installed)
>  * Building your Distro (Completing the core build-out adding your chosen
>  apps and utilities and configuring)
>  * Making your Distro distributable (How to make a liveCD of "your
>  distro", how to make an installer script...)

I think it would be really cool if this is how it worked.


More information about the lfs-dev mailing list