Planning an overall direction for LFS

Robert Daniels 0m3g4_w34p0n at
Thu Feb 28 18:21:20 PST 2008

On Thursday 28 February 2008 19:23:21 Jeremy Huntwork wrote:
> Hello All,
> Please bear with me... this is a long post, although I tried to keep
> it simple and easy to read.
No problem.  Such an important and complex topic should have long 
discussions. ( Though not too lengthy, or nothing will ever get done! )

> The reason for this, I think, is because the discussion is taking
> place among LFSers. :) We're all a bunch of control-freaks who like
> to do things our own way. Therefore, when we talk about an automated
> system with package management, or redesigning the core of how LFS is
> presented and used, we need to take this personality trend into
> consideration and maximize on customization, flexibility and
> modularity.
> The two main attractions of LFS are its educational value and the
> flexibility it offers to fully customize every aspect of the system.
> Whatever we do must focus on meeting those two goals.
> Package management is proving to be a very personal thing, especially
> to advanced users. I don't think we want to dictate to our end users
> exactly which method to use, or even that they must use package
> management. (More on how to handle that in a minute.) If we do choose
> a particular implementation, more than perhaps any other change we
> make, this has the potential to drive away users.
Agree 100% 

> 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. It will all still be a
> part of the same whole and the workload combined, but the modularity
> will allow for choice.
At first I didn't like the idea of a merge, or modules, but as I think 
about it, it makes sense.  LFS is great, but is missing a couple 
important things from BLFS like gpm, dhcp, and a web browser.

Then BLFS, as great as it is, has grown so large as to be a maintenence 
burden.  Along with the general low amount of activity, I think this is 
a big part of why blfs 6.3 has not yet been released.  Then, as a user, 
looking at BLFS for the first time, it is easy to be overwhelmed by the 
number of packages available.

> The main LFS module can be about the final system. Teaching users
> _concepts_ of the system, locations of key config files, useful shell
> tricks and tips, information about packages, examples of how to use
> the packages in a practical way, etc, etc. This should make LFS
> somewhat more accessible and easier for end users to pick and choose
> what it is they need out of it.


> The option to bootstrap a temporary toolchain is just an example. But
> it should give you an idea of how we might make LFS a bit modular.
> To cover PM, we can create a very generic spec file for each package
> in such a way that an end user can either use it in their own custom
> scripts, run the commands manually, or with any number of PMs
> available. To that end, it may be necessary to maintain specific
> modules for the more advanced PMs with directions on how to employ
> the PM of your choice.
> To automate it all, again, when designing the system from the start,
> we make provision to snap-in whichever PM module a user has chosen.


> Gerard agreed with most of the above, although he was uncertain about
> the option to skip making your own temporary toolchain. Here are a
> few comments he had:
> "You used the term "module" a lot. It reminds me of something I
> proposed a few years ago - a modular book. Before you read the LFS
> book, you first (on the web) use a PHP type program to pick your
> modules. Then it will generate a book for you that is tailored to
> your choices. You read that book cover to cover and you get your
> system. We just provide a set of mandatory and optional modules you
> get to pick from..."
> "...It gives all the power in the user's hands and no longer do we
> need to pick what we think is best. We'll of course need to provide a
> few options, say RPM, DPKG and other such package managers. The end
> user picks his favourite. Or makes your own - we can definite provide
> text how a package manager should work. That may be enough
> information for somebody to program their own."
> Generally, I like the idea. A PHP generated book that allows for
> customization and automation in a manner suited to the end user.
> If we go forward with this, it's going to require a great deal of
> work and help from a number of talented people, but to me, it's an
> exciting prospect.

I like the basic idea of a dynamically generated book tailored to the 
user.  I think this would great from a user's perspective.  However, 
from the development side, how complex would a system like this be?  
The *LFS projects already suffer from a low number of developers, and I 
wouldn't want to raise the barrier of entry for starting on 
development.  If this goes through, would I need to then learn PHP in 
addition to Docbook? Instead of?

> Any thoughts? Do you like the above ideas (or some of them)? Does it
> spark any further ideas?
> Sorry for the length, I hope it wasn't too much of a pain to read.
> --
> JH

In large part, I agree with what has been said.  Another note on the PM, 
it may be a good idea to only include one PM in the first version of 
this new model, get things out the door.  Then add support for other 
PMs in later versions.

Robert Daniels

More information about the lfs-dev mailing list