[lfs-dev] Build method revisions

Ken Moffat zarniwhoop at ntlworld.com
Thu Mar 1 12:56:26 PST 2012


On Thu, Mar 01, 2012 at 12:33:21PM -0800, Qrux wrote:
> 
> 3) Commit-triggered build would require something that pulls the scripts out of the book pages and assembles them in a build-able format.  Does that exist?
> 
 For LFS, the editors normally build the whole of LFS before
committing, although obviously we can make mistakes in what we
commit, and sometimes people will make a trivial change without a
full build.

 For BLFS it's very different - we only build a package a few times
before we commit it, so there are usually possible dependencies that
don't get used, or optional dependencies that we always supply.  More
importantly, we can't build every package which *might* use this
package.

 For myself, I normally don't update the book until I've built the
new version as part of a full build [ except, if it's a vulnerability
fix, I'll just update my running desktop systems ].  Often, but not
always, this picks up any issues elsewhere.  The gst-plugins are
particularly nasty for building more plugins when you've added a new
and not obviously related package, so that what I used in my current
system was fine, but now when I go to check the measurements
it no longer builds.  I'm sure there are other similar packages.  So,
it can only ever be a "best intentions" approach.

 The other problem with automating BLFS is that you're not intended
to build everything, nor to follow the book mechanically - if you
read a page, you may see suggestions : some may be appropriate for
you, others won't.  So, if you process the xml it might not give you
appropriate instructions.  Also, you have to apply your judgement in
deciding on optional dependencies.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce



More information about the lfs-dev mailing list