On Sat, May 19, 2012 at 8:26 AM, Jeremy Huntwork < jhuntw...@lightcubesolutions.com> wrote:
> 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. > I have been watching this thread and it seems to have gone a bit dormant so maybe now is a good time to add my thoughts. First off - Jeremy, your contributions to this project continue to amaze me. Keep it up buddy. > > (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. > OK so first let's make sure we are clear on goals, roles and responsibilities here. The thread seemed to float around a bit with some concerns about losing the "roll your own" control that the books give us. 1. Adding PM is NOT a replacement for the books. It should also be noted and clear that the purpose of this effort is not to turn (B)LFS into a binary distro. It is and always should be a cookbook so those that want can still roll their own. I really think that this effort should be a book development tool and cookbook for those wanting to learn about package management. I think the current books stay as is and PM is another off-shoot like cLFS. The books should stay independent as they have different goals. I am thinking that we attempt to leverage the (B)LFS book sources in some manner (maybe combine them into a super book) and then add the PM stuff to each page (build steps). If we go this route, we won't confuse goals and won't make the main books too hard to read. Remember we get new users all the time. Also by creating an off-shoot version of each book, we can go hog wild with educational text about package management strategies, procedures, etc and that text stays out of the main books (again because it is not the main book's goal). 2. PM is for book developers for the most part. Support for the binary packages and repository is to aid book developers. Non-book developers that want to use the packages for their own purposes can do so at any time, but the *-dev community does not support them for that purpose. If we keep these things separate, we can add value for those that are interested and reduce confusion and angst for those that are not. I am also thinking that if we leverage an "extension" of the main book sources for the PM branch, then we can leverage jhalfs (after an enhancement) or another parser to pulls the PM commands out of the book for rapid re-use. Questions about the binary repository came up. I too have some questions about that. What is the definition of 'official'? Who/What is 'official'? Who is going to vet submitted binaries? What is the standard we are going to follow? I would assume binaries compiled with commands right out of the books with no extra optimization flags and such, but that should be agreed upon. Yet another good reason for PM to be a separate book. We can have a whole chapter documenting this if we need to. The separate work things also aid #3 above as well. We can document the standard workflow, tool use, etc there. Things like what you need to get started building a book development environment, a reminder of selection criteria used for the PM tool of our choice (just to help us remember why a certain tool was picked as our memory fades), etc. One tool I think we will need is a spec file generator. This goes back to my thought about putting xml tags in the book source that is parsed out. > 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. > WRT BLFS book development specifically. Lots of commentary about dependencies - both build and run-time ones. Part of the PM project would be to standardize how we create packages. My thinking is to create a package for the required deps and the come up with a way to generate other "versions" of a package with the run time deps built in. Keeping PM in a separate book will give us this option to document and explain. > 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. > Which I would like to see revived and I think support of the binary packages as part of a build script for the LiveCD would certainly help keep it up to date. > > 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. > > Agreed, this is another reason why I am in favor of doing this in a separate book. [snip] I would like to contribute to this one, but won't be able to until this fall when I can get some other things off my plate. Never seems to be enough time to do what I want to do. James
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
