On 5/31/12 4:41 PM, James Robertson wrote: > 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.
Thanks James, :) > 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). Hmm, possibly. I'm wary of new projects/books (given their life span) but I also see the value in what you're saying about keeping the book unchanged. > 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. Yep, all good questions. I don't know the answer yet. Perhaps the answer is to do like I suggested in another message and show a proof of concept first, then we can tackle the hard decisions as the concept gains ground. > 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. Yep, the parser/generator will need to be one of the first things tackled. > 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. Not sure I'm following this exactly. Do you mind being a little more specific or provide an example? > 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. Nice! Totally understood. We're all busy... some perhaps more than others. :) I look forward to working with you on it. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
