der Mouse wrote:

> > We do [need free space on md0] until someone directs pax to keep its
> > temp data (permissions on extracted files) somewhere other than /tmp.
> 
> ...or we use something other than pax to do the extract.  It's a tar
> archive, right?  Why not use tar?
> 
> If our stock tar is too bloated for the install disks (it *is* a GNU
> program; there's probably a whole Lisp engine in there or something), I
> can offer my tar to the cause.  Even as it stands (i386)
> 
> [Truly-Delicious] 10> size /usr/bin/tar           
> text    data    bss     dec     hex     filename
> 258016  8192    12740   278948  441a4   /usr/bin/tar
> [Truly-Delicious] 11> size ~/.local/bin/tar
> text    data    bss     dec     hex     filename
> 172000  4096    3478772 3654868 37c4d4  /home/mouse/.local/bin/tar
> [Truly-Delicious] 12> 

While on the sizes game, this is from over a year ago:

	From: Simon Burge <simonb@telstra.com.au>
	To: tech-install@netbsd.org
	Subject: tar & install
	Date: Sat, 23 Jan 1999 13:40:56 +1100
	Sender: simonb@balrog

	Motivated by the recent "discussion" in switching from using
	GNU-tar to pax on the installation media, I had a look at the
	size of these programs, and compared that with the first version
	of pdtar I could find (volume 7 of comp.sources.unix).  Here's
	the size of the dynamic binaries under NetBSD 1.3.3 on a pmax:

		text    data    bss     dec     hex     filename
		174966  7592    1784    184342  2d016   tar
		116986  1908    33684   152578  25402   pax
		33685   712     1052    35449   8a79    pdtar

	That version of pdtar doesn't have the --one-file-system or -C
	options that sysinst uses.  The -C can be removed from sysinst
	by "( cd rahrah; tar ...)", and the --one-file-system option
	can't be too hard to add.

	Savings of approx. 80kB of code would certainly help, and
	there's probably some stuff that could be left out to make it
	smaller.  Is there any interest in adding this in distrib/tools
	as tar_x ?

	Simon.

The reason I chose dynamic binaries was the assumption that the bits of
libc that tar/pax/whatever would use would be used by other programs
and since everything was crunchgen'd together it wasn't worth including
those numbers.  From a later message (in response to the dynamic/static
question), here's the static numbers for the same:

	text    data    bss     dec     hex     filename
	410568  10260   25676   446504  6d028   /usr/bin/tar
	388568  5652    57544   451764  6e4b4   /bin/pax
	258088  3344    24904   286336  45e80   pdtar

Also, for the 1.4.1 build on a pmax here's the largest components of
it's ramdiskbin:

	vlad:distrib/pmax/ramdisk 130> size obj.pmax/*.lo | sort -n | tail
	29800   432     18752   48984   bf58    obj.pmax/disklabel.lo
	41848   1456    271884  315188  4cf34   obj.pmax/newfs.lo
	66488   784     904     68176   10a50   obj.pmax/ed.lo
	69784   1664    7397    78845   133fd   obj.pmax/tip.lo
	72584   2688    329007  404279  62b37   obj.pmax/gzip.lo
	90456   816     888     92160   16800   obj.pmax/fsck_ffs.lo
	104792  704     40008   145504  23860   obj.pmax/pax.lo
	106136  12448   34324   152908  2554c   obj.pmax/sysinst.lo
	125688  4496    24992   155176  25e28   obj.pmax/ftp.lo
	145624  3632    2984    152240  252b0   obj.pmax/sh.lo
	vlad:distrib/pmax/ramdisk 131> ls -l obj.pmax/ramdiskbin
	-rwxrwxr-x  1 root  wsrc  1822996 Aug  7 23:33 obj.pmax/ramdiskbin*

Simon.