From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 27501 invoked from network); 10 Aug 2020 02:26:42 -0000 Received: from krantz.zx2c4.com (192.95.5.69) by inbox.vuxu.org with ESMTPUTF8; 10 Aug 2020 02:26:42 -0000 Received: by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 736e5b2f; Mon, 10 Aug 2020 02:01:31 +0000 (UTC) Return-Path: Received: from pb-smtp2.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTPS id 65739c91 (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO) for ; Mon, 10 Aug 2020 02:01:29 +0000 (UTC) Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 50B3F7F12F; Sun, 9 Aug 2020 22:26:33 -0400 (EDT) (envelope-from tmz@pobox.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from:to :cc:subject:message-id:references:mime-version:content-type :in-reply-to:content-transfer-encoding; s=sasl; bh=ijCrqmBrwKEQf D60q0IYaunKkOQ=; b=DnhN75d0qPkAIEFZGxGHiXFaL3p32fG4hXwS5hdfdbZt0 bq/izh25KT/eN7aBPYzsgvXjJKo+7Lzg/IXF9mDhsYk0p3x3EQp8J4QG6WGUualS HBEY5hhkMTjY24VwtfwZowVK+tm1Cs3k0NDxafMHn3tU3VIRqHSmBx+A8//46A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from:to:cc :subject:message-id:references:mime-version:content-type :in-reply-to:content-transfer-encoding; q=dns; s=sasl; b=Sf9Hhn3 Rz8tUechxSDotkCfXpk7L74og0dbptvWB5CpFBBKMd/pnNvi0+jueGzBUqoeQwyi j6Yc/MtyGufBWg0N7az3JwBxgeEDGbPRMQYCl+gREJgSJ/e/SqUgWQWpYgyvR9ar mvSt9JfP0fOjYwGugeZjXK1fkh9J2mdHz9UI= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 496547F12E; Sun, 9 Aug 2020 22:26:33 -0400 (EDT) (envelope-from tmz@pobox.com) Received: from pobox.com (unknown [173.67.178.181]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id AD4AB7F12C; Sun, 9 Aug 2020 22:26:32 -0400 (EDT) (envelope-from tmz@pobox.com) Date: Sun, 9 Aug 2020 22:26:31 -0400 From: Todd Zullinger To: cgit@lists.zx2c4.com Cc: Christian Hesse , Hanspeter Portner Subject: Re: [RFC/PATCH] t0107: support older tar in zstd untar test Message-ID: <20200810022631.GV540@pobox.com> References: <20200808194158.1257195-1-tmz@pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20200808194158.1257195-1-tmz@pobox.com> X-Pobox-Relay-ID: E7DF0AFC-DAB0-11EA-B952-2F5D23BA3BAF-09356542!pb-smtp2.pobox.com Content-Transfer-Encoding: quoted-printable X-BeenThere: cgit@lists.zx2c4.com X-Mailman-Version: 2.1.30rc1 Precedence: list List-Id: List for cgit developers and users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: cgit-bounces@lists.zx2c4.com Sender: "CGit" Yesterday, I wrote: > Does cgit intend to require GNU tar? If not, perhaps we should instead > justify this primarily for compatibility with a wider range of tar > implementations in addition to supporting older versions of GNU tar? The more I thought about it, the more I liked that idea. It makes it simpler for new compression algorithms to re-use the tests for the existing algorithms. We could potentially even create a helper function to handle each compression algo. So here's that version in patch form. -- 8< -- Subject: [PATCH] t0107: support older and/or non-GNU tar The untar tests for various compression algorithms use shortcut options from GNU tar to handle decompression. These options may not be provided by non-GNU tar nor even by slightly older GNU tar versions which ship on many systems.=20 An example of the latter case is the --zstd option. This was added in GNU tar-1.32 (2019-02-23)=B9. This version of tar is not provided by CentOS/RHEL, in particular. In Debian, --zstd has been backported to the tar-1.30 release. Avoid the requirement on any specific implementations or versions of tar by piping decompressed output to tar. This is compatible with older GNU tar releases as well as tar implementations from other vendors. (It may also be a slight benefit that this more closely matches what the snapshot creation code does.) =B9 Technically, the --zstd option was first released in tar-1.31 (2019-01-02), but this release was very short-lived and is no longer listed on the GNU Tar release page. Signed-off-by: Todd Zullinger --- tests/t0107-snapshot.sh | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tests/t0107-snapshot.sh b/tests/t0107-snapshot.sh index c164d3e..8ea95ce 100755 --- a/tests/t0107-snapshot.sh +++ b/tests/t0107-snapshot.sh @@ -25,7 +25,7 @@ test_expect_success 'verify gzip format' ' =20 test_expect_success 'untar' ' rm -rf master && - tar -xzf master.tar.gz + gzip -dc master.tar.gz | tar -xf - ' =20 test_expect_success 'count files' ' @@ -67,7 +67,7 @@ test_expect_success LZIP 'verify lzip format' ' =20 test_expect_success LZIP 'untar' ' rm -rf master && - tar --lzip -xf master.tar.lz + lzip -dc master.tar.lz | tar -xf - ' =20 test_expect_success LZIP 'count files' ' @@ -109,7 +109,7 @@ test_expect_success XZ 'verify xz format' ' =20 test_expect_success XZ 'untar' ' rm -rf master && - tar --xz -xf master.tar.xz + xz -dc master.tar.xz | tar -xf - ' =20 test_expect_success XZ 'count files' ' @@ -151,7 +151,7 @@ test_expect_success ZSTD 'verify zstd format' ' =20 test_expect_success ZSTD 'untar' ' rm -rf master && - tar --zstd -xf master.tar.zst + zstd -dc master.tar.zst | tar -xf - ' =20 test_expect_success ZSTD 'count files' ' --=20 Todd