jhuntwork at linuxfromscratch.org
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
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
More information about the blfs-dev