[lfs-dev] Once more: Package Management

Jeremy Huntwork 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 mailing list