Planning an overall direction for LFS

Jeremy Huntwork jhuntwork at linuxfromscratch.org
Thu Feb 28 17:23:21 PST 2008


Hello All,

Please bear with me... this is a long post, although I tried to keep it 
simple and easy to read.

Gerard invited me to share some of my ideas with him privately about our 
recent discussions on lfs-dev. What follows is mostly what I presented 
to him, with a summary of his comments at the end.

We've gotten a lot of input from a lot of different people about where 
to go next. Unfortunately, due to a variety of perspectives and the 
different ways in which individuals have been used to using LFS, not 
everything meshes together and I don't think we yet have a clear picture.

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.

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.

For example, (I've mentioned this before, but I want to bring it up
again in light of recent suggestions) consider the whole toolchain
purity issue. LFS says it teaches users about what makes a Linux system
tick and what is going on inside it, but far more effort in the book is
focused on the idea of bootstrapping a pure toolchain, rather than what 
is going on in the final system.

I'm not suggesting that we abandon the bootstrapping method. What I'm 
suggesting is that we make the temporary toolchain into its own module. 
We give the end users a choice to completely bootstrap their own system 
as in current LFS implementations, or, we let them download a packaged 
temporary toolchain that we have generated based on those same 
instructions and start with what now corresponds to chapter 6 in LFS.

So, the toolchain module is still there and a necessary aspect of LFS,
but it isn't required that each user understand fully toolchain purity
to get something beneficial out of LFS. They can get right to where they
wanted to go in the first place: what makes a Linux system tick and how
can I create it myself?

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.

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



More information about the lfs-dev mailing list