Re: VM images for FreeBSD

On Nov 3, 2011, at 9:31 PM, Daniel O'Connor wrote:

> 
> On 19/10/2011, at 21:19, Alexander Yerenkow wrote:
>> I can't specify to pkg_add that it should treat /zpool0/testroot as root, as
>> I need (so record really should be _at_cwd /usr/local)
>> Instead, pkg_add allows me to make chroot, which as you understand is not
>> good (In specified chroot all required by pkg* binaries/libraries must
>> exists, unfortunately I can't specify some empty dir and install there).
> 
> Hmmm, why is it empty?
> When I have made something analogous I did an installkernel/world into a directory and then chroot'd in there and built ports. There is no reason you couldn't pkg_add from a local mirror (or nullfs mount a local package mirror directory into the chroot).

	The chroot option via the pkg_install tools is broken. Look through the PR database for more details.

>> Why is that? Because there is +INSTALL script in packages, in which
>> package/port system allows execute any code/script written by porter.
> 
> This is a feature ;)

	Except it doesn't work too terribly well on cross-compiled images or in installed worlds where the image version and the host system may not match and the script digs into the info that it needs from the kernel (one example is available here: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2007-07/msg00597.html , but I've seen other issues if things are executing something like ifconfig, geom, etc). This would probably be less of an issue if BUILD_DEPENDS was compiled with the host architecture instead of the target architecture, so the tools could be run on the build host, but assuming that that level of intelligence exists within ports is incorrect.

>> To summarize my efforts:
>> I checked 21195 packages;
>> I found 880 install scripts;
>> 
>> 3 scripts contains plain "exit 0"
>> 8 install scripts contains some perl code;
>> 17 scripts contains some additional "install" commands;
>> 70 scripts contains some chgroup/chown actions (which probably could be done
>> by specifying mtree file?...)
>> 75 contains uncategorized actions (print of license, some interactive
>> questions, ghostscript actions, tex, fonts etc.)
>> 161 scripts contains some file commands, like (ld / cp / mv, creating
>> backups, creating configs if they aren't exists etc. )
>> 166 scripts contains useradd/groupadd commands (many similar constructions,
>> not too hard to move this to .mk, in pkgng group/users can be specified in
>> yaml config)
>> 380 contains pear component registration (md5 -q * | uniq  - produces
>> exactly one result, so these all scripts are really one, could be moved to
>> some pear.mk)
> 
> Interesting stats, thanks for taking the time to do the analysis.
> 
> I think one of the reasons pkg_add is so slow is that it copies everything to a staging directory, then copies the files.. This is very tedious (obviously). I wonder if it could be modified to have a "stream" mode where it unpacks directly into the target FS.
> 
> Alternatively you could cut it in 2 conceptually and modify pkg_add so it can run it a mode where it just unpacks to a staging area, and another mode where it copies from the staging area to the destination.

	This is also why "ports" is "faster" -- it hacks around the double piped tar copy and installs _directly_ to the live system and sets up the metadata after the fact, which needless to say.. isn't very atomic :/..
	That and while .bz2 compresses better, for most cases than .gz, compressing/decompressing is slower with .bz2 than with .gz.
Thanks,
-Garrett