Automating BLFS

Jeremy Huntwork jhuntwork at
Mon Nov 28 05:03:21 PST 2005

Randy McMurchy wrote:

> I personally don't see the benefit. Automating LFS is one thing.
> BLFS is a whole different animal. There are simply too many intangibles
> that will have to be addressed: configuration, which package to use
> when you have a required dependency of packageA or packageB,
> dependencies not having instructions in BLFS, do you run the test
> suites.

Here's how I would 'address the animals' so to speak:

Configuration - Use the defaults found in BLFS. If you have a separate 
configuration for a specific package that you'd prefer to use, you can 
create a file and place it somewhere, perhaps like 
If jhalfs doesn't see a config file for the package in question it uses 
the defaults. (I wasn't sure if you meant options to pass to a configure 
script or if you meant post-install configuration. The post install 
configuration doesn't concern me too much - on almost any automated 
build a user at some point will have to go in manually and set things up 
how they like. Still, a similar setup could be used for both ./configure 
options and post-install configuration.)

Variable Required Dependencies (PackageA vs. PackageB) - In a case where 
there is a required dependency for a package that can be satisfied by 
more than one package, we could use a variable representing that 
dependency. For example, if the dependency is having an MTA installed, 
we could use the internal variable MTA and you could call make with 
something like 'make MTA=... install-[package-name]'. If the variable 
isn't set on the command line, then make will prompt for a user choice.

Test Suites - Manuel has already addressed that issue in LFS and I don't 
think it would be any big undertaking to port his solution to BLFS.

> I realize that now it will be suggested that Jeremy and Manual will
> be glad to help out in getting this done, however, my belief is that
> there will be one issue after another which will have to be addressed.

That's all part of the game, isn't it? There's *always* going to be 
something more to address. Just because something is work doesn't mean 
it shouldn't be attempted. After all, xLFS wouldn't exist if we didn't 
continue addressing issues.

> I suppose one thing is that I am just not a fan of automated builds.
> This may be tainting my opinion.

I'm curious why that is. Granted, some automated builds hide a lot from 
the user or leave them with little control. I hoped from the beginning 
that jhalfs wouldn't be like that, and so far, it seems to have avoided 
doing that.


More information about the blfs-dev mailing list