Planning an overall direction for LFS
dbn.lists at gmail.com
Fri Feb 29 07:46:41 PST 2008
On Fri, Feb 29, 2008 at 1:20 AM, Alan Lord <alanslists at gmail.com> 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