Planning an overall direction for LFS

[Robert Daniels]

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.

<snip>
>
> 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.
>

Agreed

> 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.
>

Agree

> 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