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
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
