cvs commit: src/lib/libarchive Makefile archive.h.in archive_entry.c archive_entry.h archive_entry_link_resolver.c archive_entry_private.h archive_entry_strmode.c archive_platform.h archive_read.c archive_read_support_compression_none.c archive_read_support_format_all.c ...

[Tim Kientzle]

Simon L. Nielsen wrote:
> On 2007.12.30 04:58:23 +0000, Tim Kientzle wrote:
> 
>>  Log:
>>  Update libarchive to 2.4.10.  This includes a number of improvements
>>  that I've been working on but put off committing until after the
>>  RELENG_7 branch, including:
>>  
>>  * New manpages: cpio.5 mtree.5
> 
> mtree(5) seems to be a general manual page, so wouldn't it make more
> sense to have it in src/share/man/man5 or src/usr.sbin/mtree ?

The latter does make more sense; I'll change this.  (Since there's
no history in it's current location, there's no point in a repo-copy;
I'll just delete it from it's current location and add it under
src/usr.bin/mtree.)

>>  * New read support: mtree format
> 
> This sounds interesting but I can't really figure out what it
> does... ? :) (and I couldn't find any mention in the updated manual
> pages.)

Still slightly experimental (and relies on mtree files having
an initial signature, which our mtree program doesn't yet insert).

This originated as a means for generating archives with
user-specified metadata.  (For example, create a tar archive
with entries owned by root even if you're not running as root.)
NetBSD has hacked their 'tar' program to do something similar;
this implementation allows bsdtar's much more general
archive-conversion capability to do the same thing.

With this, bsdtar can read an mtree file and do any of the following:
   * "extract" the file to disk (recreate the disk heirarchy)
        tar -xf specification.mtree
   * "convert" the mtree spec to a tar or cpio archive (especially
useful with a new mtree key I've introduced that allows specifying
the contents of a file)
        tar -cf system.tgz -z --format=pax @specification.mtree

There are particularly intriguing applications to packaging and
installation: the former is essentially a "bulk install", the
latter generates a tarball from the exact same spec for
later installation with a simple tar extract.

Tim Kientzle