[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Testing pax on platforms was Re: Using pax instead of cpio in dist.sh

From: Tobias Ringstrom <tobias_at_ringstrom.mine.nu>
Date: 2004-03-30 00:00:43 CEST

Ben Reser wrote:
> On Mon, Mar 29, 2004 at 11:07:22AM -0800, Justin Erenkrantz wrote:
>
>>I think you've missed the point that we shouldn't have an 'official' build
>>machine nor a dedicated RM. Note that if I do a roll, it'll likely either
>>use OS X's pax or Solaris 9's pax.
>
> This is how I feel as well. If i do a release it'll be with a GNU pax
> on Mandrake.

What I was trying to say was that we don't need to test if the USTAR
format works. We did that when we started to use cpio instead of GNU
tar to create the tarballs. We will just use another tool to create the
same thing -- hopefully a tool with no bugs.

The only reason to test pax would be to test for bugs in the one that
will be used to produce the official tarball. If five different pax
implementations and versions will be used, they should either all be
tested, or none of them needs to be tested. Pax produces USTAR files.
That is the purpose of pax. There is no reason to test the pax in RHL9
if you will use OS X to produce the tarballs. That was all I meant.
That said, I think we can trust pax to be correct, and we don't need to
test it. I'm not against testing it, of course. I just wanted to
explain why I though that it was unneccessary to test it.

The decision (or even discussion) that we shouldn't have a dedicated RM
did not happen publicly, and the outcome is not publicly available
except in the form of little hints, so who can be blamed for missing
that point?

/Tobias

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 30 00:01:02 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.