On 12/15/05, Ken Moffat <[EMAIL PROTECTED]> wrote: > On Thu, 15 Dec 2005, Dan Nicholson wrote: > > 1. The build automatically loops to the beginning, skipping the first > > few stages: create symlinks, create devices, mount file systems, > > create directories, etc. for all but the first iteration. > > > > That's my prime objection to Greg's method - we always tell people > fbbg, but the comparison takes a shortcut.
Right, but for the purposes of testing, the environment should be as consistent as possible. That's standard procedure for running a test in any field. And why would you recreate the devices, directories and symlinks if you were still in the chroot? Setting up a test environment is different than putting your system in a production running state. > > 2. For all stages he stops short of installing many of the custom > > configuration files like /etc/profile, /etc/fstab, etc. Keeps the > > building environment consistent. This is what I like better than what > > Ken's tool does. I'm not sure how it removes the variables of kernel, > > modules, env vars, etc. > > > > Useful, if all you want to do is test it. For me, knowing that a new > build boots (and therefore has enough of blfs for me to use it, e.g. > dhcp, nfs, ssh) is always a good sign. Absolutely, you're right about those things. I certainly don't consider my build complete until I get a handful of BLFS packages in there. You could even add some of those to the test environment. We all know that where LFS ends and BLFS begins is subjective. As for booting, you're going to probably change your environment drastically, and that would invalidate the test. If you did a binary diff and found two files to be different, would you be confident enough to tell me that the difference was caused by the building method and not by the altered environment? Or vice versa? > I'm unclear what changing environment variables is likely to do to an > LFS build ? In practice, either the environment is created during the > build (e.g. new .bashrc), or a builder probably has a standard > pre-existing environment. How about LC_ALL? Creation of /etc/profile in LFS dictates you to set it to your locale, but for the build we've used LC_ALL=C (or POSIX). > That _is_ an advantage - lesstif from blfs overwrites a man page from > perl (not checked recently, but it used to), which I only noticed > when I compared a full system against the minimal system it had built. > With farce you can compare as little, or as much, as you wish (subject > to adding to expected differences for new file types such as Python > code, and new regexes) - it doesn't need a full build, it should be > usable for arbitrary packages, and you can use your own buildscripts. I have no objections to farce. It sounds like you've put a lot of effort into seeing what happens to the files in a second build. I'm arguing for keeping a sane test environment. We all know that LFS builds and boots. This tests the quality of the build, and that test is separate from the two previous questions. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
