Use the new chpathtool.

Use the new chpathtool.

If we install on a system with a different prefix, unpack in the
workdir, instead of the image dir.  We "copy" from the workdir to the
image using chpathtool, which behaves as a cp -a.

chpathtool was changed to copy file by file, changing paths it finds in
files to overcome the following problem.  chpathtool was used in a piped
fashion, like this:

bzip2 -d file | chpathtool | tar -x

in this way, chpathtool operated on the raw tar-stream, changing paths
it saw over the stream.  This has the following advantages:
- not only rpaths, library locations, or hardcoded paths to conf files
  were changed, but also the location of the files in the filesystem
  themselves, as chpathtool also changed the tar envelope
- just one run over the stream, simple, easy and cheap from an fork/exec
  perspective
- no need to deal with file attributes, creation modes, etc, tar dealt
  with that, chpathtool only changed paths where appropriate

However, when doing the path changements, chpathtool inserts padding
bytes at the end of each string it sees, in order not to break offsets
stored in e.g. programs to point in the TEXT or DATA spaces.  Because
text files are in the tar stream, chpathtool sees the end of string at
the end of such text file, and inserts the padding null-bytes there.
However, tar still has an administration for each file of its size, so
as result, tar writes the padding null-bytes to the text files.  In most
cases this doesn't hurt, however, some applications, such as GHC get
confused by it, because EOF isn't found, but null-bytes don't make sense
for them.

The only way to fix this, without interpreting the tar envelope, is to
use chpathtool per file.  chpathtool doesn't write padding bytes if it
doesn't find an end of string, which in textfiles doesn't exist (instead
you get the EOF).  Running find -exec, or with xargs results in a
serious performance problem due to numerous fork/exec calls.  Instead,
chpathtool was changed to recursively walk directories, and process all
what is in there.

Because chpathtool operates on files in this case, it needs to properly
behave, such that it doesn't change the properties of each file it
replicates.  For this reason, chpathtool's implementation grew twice its
original size in order to retain the original file's permissions,
owners, and times.

svn path=/main/branches/prefix/; revision=8105