[lfs-dev] Once more: Package Management

Jeremy Huntwork jhuntwork at lightcubesolutions.com
Sun May 20 14:08:32 PDT 2012

On 5/20/12 2:18 PM, Bryan Kadzban wrote:
> In other words, I think it'd help to only use packages to simplify
> (mostly BLFS) testing, but make them semi-public for people who really
> want them.  Don't use them at all in the actual build instructions (what
> would be the point?  :-) ), but generate the spec files, or whatever
> equivalent, from the book XML.  (This last bit might be either hard or
> impossible; I don't know.)

Yes - I believe you have hit exactly what I'm trying to propose. The 
binaries (and binary repository) aren't advertised in any way for 
general use - they aren't even mentioned in the build instructions.

For example, consider this as a very simplified version of a package page:

"Build package Blah:
      ./configure ...

    (Optionally, via package tool):
      # Grab generated spec file here...

And then the spec file, would have references to the dependency packages 
in BLFS, calling them exactly how they've been referenced in the book's 
source. I suppose here the 'optional' ones could be enabled or disabled 
by a reader. As would devs - although I think for dev purposes it might 
be useful to have built binaries with all optional dependencies enabled.

Behind the scenes, a set of tools and a defined workflow can help the 
devs to share binaries already produced via the spec files - but those 
are never explicitly shared or brought to the attention of the reader.


More information about the lfs-dev mailing list