Planning an overall direction for LFS
jhuntwork at linuxfromscratch.org
Thu Feb 28 17:23:21 PST 2008
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 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
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.
More information about the lfs-dev