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 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
