[lfs-dev] Once more: Package Management
jhuntwork at lightcubesolutions.com
Thu May 31 15:40:51 PDT 2012
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
> 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.
More information about the lfs-dev