Subject: Re: GNU tar goodbye?
To: NetBSD Userlevel Technical Discussion List <tech-userlevel@NetBSD.ORG>
From: Greg A. Woods <woods@weird.com>
List: tech-userlevel
Date: 10/11/2002 17:32:36
[ On Friday, October 11, 2002 at 13:31:27 (-0700), Bill Studenmund wrote: ]
> Subject: Re: GNU tar goodbye?
>
> Your tone above does little to encourage discourse. Your tone indicates
> that you have decided '--fast-read' is not important, and that that's
> that.

I didn't think it was necessary to go into any analysis of why
'--fast-read' was not important -- I thought it was quite self obvious,
and even if not then it would be should anyone take a moment to read
about what it does in the manual page.

> It doesn't matter why people want it, they want it. We have it now. To
> switch tar -> pax-as-tar w/o --fast-read will be a step backwards for a
> number of our users.

None have spoken up about this particular "feature" yet.  Who are these
users?  How many of them are there?  How many of them _really_ care
about this particular feature?  How many would notice if it were a no-op?

> Also, we're talking about a time optimization. By its definition, things
> will work w/o it, just slower.

Exactly my point.

> Arguing we don't need it because things
> work w/o it misses the point.

These kinds of optimisations are things that can be (re)added at any
time in the future.  They're really not necessary to get basic
functionality out the door.

> One of the main reasons we want it is for supporting binary packages. One
> of the first things we do is grab the +CONTENTS file. There will be only
> one, and it usually is at the front of the file. So it's REALLY SILLY to
> read the whole file to find out that there isn't another copy of the file
> we knew there was only one copy of.

I offered patches to make pkg_* mostly work with the native 'pax'
interface quite a long time ago.  I think the PR is still in the
original open state with only a mostly un-related comment attached to it
since.

Yes those patches basically ignore the optimisations that would be
possible with support for a "stop when we've found the first instance of
all the files we're looking for" feature in pax, but like I say those
kinds of things can easily come along later.

> So no --fast-read == about 200x system time increase, and a LOT of user
> time.

Sure but it's not really a "LOT of user time" because it's time that's
not repeated very often for any given user.  I use binary packages
exclusively for some systems I support and I haven't noticed a lack of
'--fast-read' wasting any of my time in any ongoing way.

(well, if someone uses an un-optimised pax or tar, as I do, in an
environment where PKG_PATH is pointed at a remote FTP URL, as I do on
occasion, and they happen to run pkg_info in certain ways, then even
worse performance problems in pkg_info itself are almost immediately
made much more readily apparent....  :-)

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>