[lfs-dev] Once more: Package Management

Jeremy Huntwork jhuntwork at lightcubesolutions.com
Tue May 22 19:18:26 PDT 2012

On 5/20/12 7:09 PM, Ken Moffat wrote:
>   The more I think about this, the less happy I am.  Point 2 doesn't
> really help editing BLFS as far as I can see (upgrading a package
> usually needs several builds - typically, for me, a first to see if
> it actually works when I use it, then others to get nice clean
> measurements, check what is in the DESTDIR (or INSTALLROOT), and
> review options for the optional dependencies and any testsuite.

Actually, from my experience a packaging tool eases a lot of the pain 
inherent in the process you've described. Auto-fetching of sources 
(including dependencies), auto-preparation of a clean build tree, 
post-build reports of what files have been included in the package and 
what (if any) auto dependencies have been discovered.

Re-doing a build if issues or errors are found (including, if necessary, 
setting up an entire chroot system as well) becomes a matter of one 
command, instead of several.

>   Then there is the question of dependencies - in BLFS we don't
> normally tell people how to use optional deps.  Sometimes they are
> picked up automatically, but many times you have to pass a switch to
> get them used.  The instructions in BLFS are hopefully correct, but
> they don't suit everyone.
>   I'm also wary of standard workflows - my own LFS build is different
> enough (nothing updated in /sources, because that is an nfs mount on
> my systems, and with efforts to remove many of the static libraries)
> that I expect pain.  And that's just for LFS.  For BLFS, I suspect
> this sort of change will actually increase my workload and therefore
> reduce my contributions.

This is one of those scenarios where I think it's difficult to see how a 
thing will be useful or beneficial until after you've actually tried it 
out. I'm not guaranteeing you'll think it better, more useful or simpler 
- though my belief is that it does actually simplify the process of 
correctly building and documenting the build of an individual package, 
once the tools are available and the infrastructure in place.

>   The intention is good, but I'm not at all convinced that the plan
> will help.

Perhaps it really is something that needs to been seen and experienced. 
I can do as I planned and document the procedure to build in PM with LFS 
and set up the basic infrastructure required (a web server with a public 
binary repo). Once that's in place, anyone who wants to test out the new 
workflow can try it and offer thoughts, comments, suggestions. Then 
perhaps a decision can be reached as to whether it be actually 
implemented for either LFS or BLFS. This way, too, at least the 
documentation will have been done.

Anyone interested in helping with the above, or should I just report 
back here when I've accomplished this on my own?

>   Also, can I really trust whoever is permitted to edit a book (I'm
> assuming that part of the aim is to get more people editing in BLFS
> ?) to have an uncompromised system, and to not want to upload
> compromised binaries ?  For the xml in the book, and for patches, we
> can look at what is being changed.  For a binary, how do we know
> what was done to it ?  Distros have build machines with restricted
> access and some degree of security.  Is LFS going to need signed
> binaries and a ring of trust ?

This is a great question, and I'm still not sure the best way to answer 
it. Perhaps it should be tabled and reconsidered if and when either book 
looks to actually adopt the workflow as 'official'.


More information about the lfs-dev mailing list