From owner-freebsd-current@FreeBSD.ORG Fri Nov 4 14:54:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC1E1106564A for ; Fri, 4 Nov 2011 14:54:52 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 756548FC08 for ; Fri, 4 Nov 2011 14:54:52 +0000 (UTC) Received: by gyd5 with SMTP id 5so2188614gyd.13 for ; Fri, 04 Nov 2011 07:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=3AcJ2hBqrE3utjJUpnEsGghLToUP54npoBpssldCeEo=; b=qe7yCPi/Phj+fqoZ/ahthFnv7yikbRkrhDmBH1dVxmz7mS6nRluo3xQHso26XATvJP IyvAPKN2Ab+NMWwN9xu+IzpJ5/ZQAyTU+5g3n6a78xVg1NF/dwBsin+f4qTxpF0WvIhd QEZgLDiWKNpUNPL/sM6V/otI/9ZPba5lyj5UY= Received: by 10.236.124.17 with SMTP id w17mr20956373yhh.126.1320418491655; Fri, 04 Nov 2011 07:54:51 -0700 (PDT) Received: from [192.168.20.5] (c-24-6-49-154.hsd1.ca.comcast.net. [24.6.49.154]) by mx.google.com with ESMTPS id c44sm15667297yhm.5.2011.11.04.07.54.49 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Nov 2011 07:54:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <0DBBB027-DB51-4245-8DC5-EC5F98D66777@gsoft.com.au> Date: Fri, 4 Nov 2011 07:54:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0DBBB027-DB51-4245-8DC5-EC5F98D66777@gsoft.com.au> To: "Daniel O'Connor" X-Mailer: Apple Mail (2.1084) Cc: Warren Block , Alexander Yerenkow , freebsd-current@freebsd.org Subject: Re: VM images for FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 14:54:52 -0000 On Nov 3, 2011, at 9:31 PM, Daniel O'Connor wrote: >=20 > 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 @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). >=20 > 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. >=20 > 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.h= tml , 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; >>=20 >> 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) >=20 > Interesting stats, thanks for taking the time to do the analysis. >=20 > 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. >=20 > 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=