Alphabetical branch status report (LONG)

Ken Moffat ken at linuxfromscratch.org
Thu Dec 15 18:23:37 PST 2005


On Thu, 15 Dec 2005, Dan Nicholson wrote:

>
> It sounds like Ken's scripts do a great job of doing the comparison.
> What I like about Greg's scripts is deciding what's being compared.
>
> 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.

> 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.  These files are what I called 
'policy' earlier.  If you want to use similar buildscripts to only 
install certain files, or a script to sed the lists of files to compare, 
farce won't complain.

  Kernel modules might match, or they might differ, or not be present. 
I'm trying not to be prescriptive in how farce is used - if these do 
differ, I expect the builder will know why, and therefore recognise that 
they changed the .config, or the kernel version.  The compressed bzImage 
is a different matter - I skip that because compiling the same source at 
a different time will change the date/time which is in the text, and 
therefore the size of the compressed file can change.

  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.

  For the kernel, apart from not trying to look at differences in 
bzImage/vmlinuz I just change known kernel version formats into tokens 
in my infamous regexes.  For example, lots of the perl files are 
actually text telling you the kernel version and date/time when it was 
compiled.  Change these to tokens for known format permutations and you 
don't lose any information.  Yes, if you decide to start building in a 
different locale, this might alter what goes into the text, and perhaps 
put it into a different format - if that happens, farce should give you 
enough information to see which formats changed.

  Most of this should be reasonably clear from looking at the code (it's 
only two scripts), although the perl regexes are probably a hard slog 
when you first meet them.

> 3.  Copies only the necessary files to a temporary location
> immediately after the build completes.  This is more trivial, but it
> safeguards you against accidentally making an unalterable change on
> your system later.
>
  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.

Ken
-- 
  das eine Mal als Tragödie, das andere Mal als Farce


More information about the lfs-dev mailing list