On Thursday February 28 2008 08:23:21 pm 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. > > 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.
I think we don't necessarily need a package manager to have package management. If we document every file installed, it's size, and it's use, I think this qualifies as package management. It provides everything we need to manage the packages ourselves. > 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. No one has ever tried to stop this, but no one has distributed it and maintained it. By integrating alfs-lfscore, livecd-lfscore, chap6chroot.tar, and lfs, it creates better testing for everyone. Someone somewhere would build and distribute the tarballs, which use identical commands as in the books, using alfs. So there would be the LFS project, and the LFS Modules project. This would reduce duplicate code, and duplicate development. LiveCD would be a module of alfs, which is a module of lfs. I have been looking for a way to send svn diffs to a build server, which builds the book weekly, and only sends the svn diff public if the whole book builds as expected. So non-developers can check the unstable book changelog once a week if they're curious, instead of random times. This would give the LiveCD project a core binary tarball to build on so they can release the following week. In HLFS this helps me maintain a book that actually builds a system. robert
pgpjxagG1AZb8.pgp
Description: PGP signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
