Jeremy, I like your idea, having customised instructions in PHP for everyone's need is great.
I've been giving this subject a long thought since the first post, and I would like to make a suggestion, although I don't particularly know if it will be useful, but here it is: What I've thought is to have a pre-compiled toolchain, but in the following scheme: When I build my LFS setup, I always take CLFS instructions until it reaches the chroot phase, that's where I swap to LFS (with the only exception being udev, I use CLFS for that as it has a more recent version), so, I have devised something like: - pre-compiled toolchain for i486, toolchain components to be decided, ensures compilation on older systems/arches - pre-compiled toolchain for i686, toolchain components to be decided, ensures compilation on newer systems That's what I basically do, once I finish the temporary setup, I make a tarball and I use it for the final step, so in the end, we could have the book halved, no need to worry about toolchain compilation, just system install, of course, we would need aditional FTP space for users to be able to download the toolchain that fits their purposes. Of course, this would apply for x86, other arches would need their pre-compiled toolchain, but if this scheme could be used, I'd be willing to contribute pre-compiled toolchains. What do you think? Julio ----- Original Message ----- From: "Jeremy Huntwork" <[EMAIL PROTECTED]> To: "LFS Developers Mailinglist" <lfs-dev@linuxfromscratch.org> Sent: Friday, February 29, 2008 2:23 AM Subject: Planning an overall direction for LFS > 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 > -- > http://linuxfromscratch.org/mailman/listinfo/lfs-dev > FAQ: http://www.linuxfromscratch.org/faq/ > Unsubscribe: See the above information page -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
