I've been holding back bringing this up on-list for a while because I intended to do the bulk of the work and then present a working system to the community for comment and review. I still intend to do that, but given some recent discussions, I think the time is right to bring this up and see where it goes.
(Sorry for the cross posting, but since it involves both projects, I wanted to make sure all saw it - if possible, please reply on lfs-dev.) Proposal: 1. Adjust LFS/BLFS to auto-generate build recipes for individual packages that a packaging tool can use to create binary packages with meta information included such as dependency tracking. 2. Store 'official' copies of those binary packages in a developer package repository so that when developing (primarily BLFS) a dev can automatically pull and install into a build environment the dependencies he needs to build and create an individual package. 3. Create a standard workflow and tools whereby a developer can accomplish #2 and edit the book accordingly in an efficient, reliable way. Rationale: (B)LFS-style development by hand becomes a huge undertaking. BLFS _is_ a huge undertaking - and it's a difficult beast to maintain. In order to create a stable reference page in BLFS an editor has to have spent the time to build all of LFS, tweak it, go through current BLFS, manually install dependency packages and then carefully document the package he builds. No two developers are guaranteed to have the same environment, either, so accuracy and stability becomes an issue. The same is true of the LiveCD project, and is the main reason why it sits dead today. It is difficult to maintain when there are no packaged binaries to draw from and the entire thing is a scripted source build. Let me just say now that because (B)LFS is primarily (and probably should always be) about educating, I don't think we should require end-users to use package management. Mainly the proposal is intended to assist in development. However, if we have taken the time to incorporate PM in our dev workflow, we can make the option of building via PM tools available to readers if they wish to use it for themselves and build their own package repository. Details: (The following details assume pacman is the package manager chosen, but it could conceivably be another, such as rpm5.) 1. The end of LFS chapter 5 is modified to (optionally) build the packaging tool and any dependencies it has. 2. LFS chapter 6 is modified so that for each package a build recipe (e.g. PKGBUILD file) is generated from the book's source. A reader is given the option of carrying out the build manually or via the packaging tool. 3. LFS devs create official copies of the binary packages and install them to a semi-public package repository 4. BLFS is modified to also generate build recipes (PKGBUILD files) from its source 5. As BLFS devs work on individual packages, they can use the defined workflow and tools to generate a chroot environment with only the packages they need for build-time dependencies - they can then both produce a binary version of the package as well as document what they've done, the end product being a BLFS page which will generate/correspond to the PKGBUILD file. 6. BLFS dev updates the BLFS binary package repository with the 'official' package and other devs can now draw from and use those when working on their respective package. There are, I'm sure, both positives and negatives to this proposal, and I'd like to hear everyone's thoughts. I intended to do all the development in the jh branch, but if there are more parties interested in helping this development, then I'm also open to sharing the workload and perhaps creating an environment where this can be done together. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
