On Fri, 16 Dec 2005, Dan Nicholson wrote:
On 12/16/05, Ken Moffat <[EMAIL PROTECTED]> wrote:
Just seemed that you were taking offense to my suggestions or you
assumed I was taking shots at your tool. If not, then that's good
because I didn't mean either.
Great
As pertains to the testing, I downloaded farce finally and had a look.
I like it a lot, and I think it handles the comparison well. In
Greg's scripts the comparison is not as detailed; this automates a lot
of what I believe he does manually. So, that's very cool. I'm not
sure I'll trust the regex replacements until I see it in action, but
that doesn't stop me from manually doing the diffs on the files
themselves.
Not trusting the regexes until you've diffed is good. Maybe farce
could generate even more output, to also show what the regexes changed
(at the moment the detailed output is only for things that still came up
as different). I'll need to think about that.
Now, I will still argue about how best to set up the test environment.
I'm not a professional tester or analyst either, but it seems common
sense to me to minimize the number of variables when hunting down a
problem.
I agree that it is necessary to reduce the number of variables once a
problem has appeared.
For this reason, I agree with Greg's decision to stop short
of installing all of the configuration files and immediately rebuild
while still in the chroot. You mentioned setting LC_ALL in your build
scripts. What if someone else doesn't? Are their results reliable?
If LC_ALL isn't set correctly, then the results may well not be
reliable. But, I'd expect that to show in build or testsuite failures.
You sound like you've done the recursive build a number of times and
anticipate these differences in farce. I'd rather nip that one in the
bud and just keep the same environment.
Not exactly a recursive build: if a system builds itself again, to my
satisfaction, and builds (once) the parts of blfs I care about, I regard
it as ok. The recursive build is, or was, based on three builds to
identify which files always differed. I settle for a rebuild.
FWIW, this is the method I'll be taking. I'm gonna start hammering
out builds on Christmas. I'll be out of town for a week, so there's
nothing but spare cycles.
Dedication, using all that drinking time ;)
1. Build Ch.5 and Ch. 6. Copy important contents of / to temporary
location. I could probably do this with filelist, but I'll still copy
anyway. This includes /boot, /bin, /etc, /lib, /opt, /sbin, /usr and
/var.
Filelist only creates a list of which files exist (for a user, exist
and can be read, I think). If you're going to build in-place, you'll
HAVE TO copy them somewhere (a tarball will do, but you need the disk
space for two trees, or systems, at a time when farce is run, plus a few
MB for the results [ diffs of binaries can be big ].
2. Iterate Ch. 6. Start Ch. 6 at the beginning, ignoring the
symlink, device, directory creation and the fs mount since these have
already been done. Copy / to another temporary location using the
same directories as in 1. Repeat 2 if desired to a predefined number
of iterations.
*Note: 1 and 2 are ripped from gsbuild. You could probably add Ch. 7
and Ch. 8, but I already explained my interest in minimizing the test
environment.
4. Run farce on the temporary locations from the earlier stages.
5. Ponder the exact time in my life when I became a huge geek. Iterate.
LOL
One last thing. As for "running ICA", I think this is only a name. I
only use it because most what I know about recursive building comes
from reading stuff Greg's done, and that's what he calls it. We're
both talking about the same thing as to seeing whether the build can
recreate itself. I think the only difference I can see is how to set
up the testing environment. We can call it something else if that
helps.
ICA is Greg's name, AFAIK he had rather a lot to do with it so he gets
to name it. If somebody understands it enough, and cares enough, to use
it and report back to us, that's great.
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
