There may be use cases for using flashdist, such as not having "pkg_add"
package installed for security reasons and tailoring highly customized
images ready to be flashed for FWs, NAS, VoIP GWs and so on. So, in that
sense I am sure that the size of the flash is not the only motivation now a
days.
By default if I am not mistaken, flashdist does not include the "pkg_add"
binary and therefore for the chroot suggestion you would at least need to
get the "pkg_add" binary into the flash image.
The technique used in the flashdist script for getting things installed uses
`ldd` on a binary to find it's library dependencies and have them copied to
the image. This is more likely to work at least for dinamically linked
binaries which are fairly straightforward and in which you often do not need
anymore files than the binary and shared libraries.
You could use ldd as follows for wget as example:
ldd /usr/local/bin/wget 2>/dev/null | egrep 'rlib|rtld' | awk '{print $7}'
\
|sort -u | xargs tar -cvf - | tar -C /mnt/flashdist-image -xpf -
Where flashdist-image is the directory in which you have mounted the
flashdist image
Now, if you run ldd on the pkg_add binary you would get:
ldd: /usr/sbin/pkg_add: not an ELF executable
and I am not really sure why is that. Experts comments welcome here!
Another option may be to use the -B option from pkg_add to define the
chrooted environment as the destination dir, but I can't confirm that it
would work as expected.
For packages in which the structure of required files is more complex,
daemons such as samba an the like, using ldd may not suffice and such
programs may fail to execute mysteriously. In such cases, the ktrace(1) and
kdump(1) may come in handy.
ktrace followed by the filename will produce an output file named ktrace.out
in the directory in which you run it. Then you need to use kdump command to
inspect the previously generated ktrace.out, look for files that the program
is attempting to open, particularly for the NAMI (name-to-inode) translation
in order to get a clue of what files may be missing.
A third option involves creating a chroot sandbox environment and use two
cookies to track file changes in the filesystem as described here:
http://labs.calyptix.com/openbsd-binary-patches-chroot.php
Readers familiar with OpenBSD ports will notice that this cookie technique
is borrowed from the make system in the OpenBSD ports tree.
Hope this helps
