> Learning needs to be an incremental process. Once you learn the basics, > you can go on to more advanced topics. >
Absolutely. No argument on that one. > On the other hand, setting up a initramfs may require a lot more. There > have been mentions of RAID, encrypted filesystems, LVM, and networked > FS. We could leave something out, but some have said they want > something that will work anywhere. > As we've learned in LFS' 12 years of history, there's always somebody who wants something that we're not doing. The adage "you can't please everybody" applies. If we decide to go through with this, we'll need to reach a compromise of course. Just about everybody can implement LVM. Not everybody has the hardware to implement RAID. That might become a driving force for making certain choices. But we don't need to completely ignore a RAID setup in the LFS book, even if we just make a reference to it and include links to other documentation (BLFS, hints or otherwise) that people can side-step into to then return to the LFS book once completed. It might actually be an eye opener to people that there is more than simple static partitions. At the point where we create the LFS partition (Section 2.2) we might as well make mention of other options. I am convinced this will make the LFS process seem more well rounded. There will be even more information available to make informed decisions and allow for more experimentation. I'd even want to go as far as considering adding a few options to Chapter 2. We already have the single partition model and mentioning the extra partitions (/home, /usr, etc). Would it be a bad idea to provide a full LVM2 example there too? Yes, it'll potentially increase the load on support but I feel it's worth exploring. For those that end up deciding against LVM for their build, the appropriate packages in the book can then be skipped. This means the LFS book will start to include more optional packages as a result and not everybody is likely to install all of them anymore. I don't feel that's a deal breaker. In the end it'll take more work to maintain the book and more work to test the various scenarios we "officially" provide. It'll make the book a bit more complex as choices have to be made when it comes to installing packages. The added value all that provides is well worth the extra work in my opinion. > starting to build Chapter 5. This IMO is not "From Scratch". I suppose > that the argument can be made that running fdisk from the host is not > "From Scratch" either, but it feels much closer to me. > That's one of those compromises we'd have to decide on. There's always a downside to every good idea I suppose. > There are others. Clearly we don't have to build everything, but the > first decision is what to omit. Do we ask the user to build a subset > just for an initramfs and then go back later if a full installation is > desired? > If an initramfs "shell" is created already, then adding more to it is easier than trying to add an entire initramfs well after the fact. The list I snipped is extensive and seems a little much at first glance. Definitely some decisions will need to be made. > My overall impression is that BLFS is the right place for this with > links to the appropriate packages that need to be built. Forward > references in Chapter 2 and 8.3 (Kernel) and 8.4 (Grub Config) would be > appropriate. > My "gut" feeling says that a combination of LFS changes along with forward references to BLFS for other/more detailed/exotic options would be the best of both worlds. You can't put everything in LFS. I think everybody will agree on that. Adding more of what has become "common" these days on many systems to LFS would be worth exploring. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
