[lfs-dev] Once more: Package Management

Jeremy Huntwork jhuntwork at lightcubesolutions.com
Sat May 19 06:26:31 PDT 2012

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.

(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.)


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.


(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.

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.

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.


(The following details assume pacman is the package manager chosen, but 
it could conceivably be another, such as rpm5.)

1. The end of LFS chapter 5 is modified to (optionally) build the 
packaging tool and any dependencies it has.

2. LFS chapter 6 is modified so that for each package a build recipe 
(e.g. PKGBUILD file) is generated from the book's source. A reader is 
given the option of carrying out the build manually or via the packaging 

3. LFS devs create official copies of the binary packages and install 
them to a semi-public package repository

4. BLFS is modified to also generate build recipes (PKGBUILD files) from 
its source

5. As BLFS devs work on individual packages, they can use the defined 
workflow and tools to generate a chroot environment with only the 
packages they need for build-time dependencies - they can then both 
produce a binary version of the package as well as document what they've 
done, the end product being a BLFS page which will generate/correspond 
to the PKGBUILD file.

6. BLFS dev updates the BLFS binary package repository with the 
'official' package and other devs can now draw from and use those when 
working on their respective package.

There are, I'm sure, both positives and negatives to this proposal, and 
I'd like to hear everyone's thoughts.

I intended to do all the development in the jh branch, but if there are 
more parties interested in helping this development, then I'm also open 
to sharing the workload and perhaps creating an environment where this 
can be done together.


More information about the lfs-dev mailing list