Hi Christos,

I'm writing you as the pax-as-tar maintainer with a wish for a change:
Gavan pointed me at the fact that using pkg_info on a x11-links binary pkg
(or any other meta-pkg) won't work, as it doesn't have all the files a
"normal" package has:

	miyu% pkg_info /usr/pkgsrc/packages/i386/All/x11-links-0.23.tgz
	tar: WARNING! These patterns were not matched:
	+MTREE_DIRS
	pkg_info: extract of /usr/pkgsrc/packages/i386/All/x11-links-0.23.tgz 	failed
	pkg_info: error during unpacking, no info for 	'/usr/pkgsrc/packages/i386/All/x11-links-0.23.tgz' available

Well, guess what, the problem is tar(1) returning different error codes on
1.6.2 (our hacked gtar) and 2.0 (pax-as-tar) when a filename is given to
display (tar -t) or extract (tar -x) that is not contained in the archive,
like +MTREE_DIRS.

On 1.6.2, tar returns 0 in that situation, for both --fast-read present or
not. On 2.0_BETA, tar returns 1 on that situation, again for presence and
absence of --fast-read. This difference explains the failure, as pkg_info
tails if a value != 0 is returned.

I see two ways to fix this:
a) move back to returning 0 in that case
b) return some other error that makes it clear what failed in that case,
   e.g. 2

For comparison,
 * Solaris' /usr/bin/tar returns 1 if it can't extract a file
   and 2 if something else went wrong (while they don't document details
   on the error cases!),
 * GNU tar returns 2 in several cases, while I couldn't find documentation
   of errors in either the manpage nor the info-page
 * SUSv3 doesn't cover tar at all, and for pax it just says that a
   non-zero exit status should be printed if a file can't be extracted
   from an archive.

As such, I'd say we should go for solution b) and document it properly, so
that pkg_info can make use of it.

It would be good if we could get those changes into 2.0 ...

What do you think?


 - Hubert

-- 
                         ,,_
If wishes were wings,  o"   )~  would fly.            -- Go www.NetBSD.org!
                        ''''