From owner-svn-src-head@freebsd.org Fri Nov 17 19:16:55 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 488CBDE14DE; Fri, 17 Nov 2017 19:16:55 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f52.google.com (mail-it0-f52.google.com [209.85.214.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 94B4A71F7A; Fri, 17 Nov 2017 19:16:54 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f52.google.com with SMTP id b5so5272236itc.3; Fri, 17 Nov 2017 11:16:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=Dj2tr9LEH4dewnPxaH57zP/rba6lCAFk6D9cFrUvUb4=; b=EixWeEzfcFn6xzuseAa/1rWuu6q1W2E+lCXY8lXVUeNIieJ0rE62L8bp15VJMIhVd6 8C9vsmi8fQCvnjUjM1Eskdlp8ywxAsoLWrPdvrYGQI1a5jKentkC0L9ZzqPzrxwSs5Ib 8Pf1y9Ea6ahzjXn0W7rFpBBj7ibTBg54z0KxD3Rc2bYCCamE0mWdUP7kBX2LZEG+TShj UJAVMcfjLbpfpMrhCdpJLPuW1oWXD/78JzA/YwAh2K5jJ7WCTtvYkTmo4JE2OoBk3BdH 7V/zW+956uVI2tYgvuPuqf17g7y0w3GVulbC/DOOggsIa4N52NiEV8LeeFtpXxFitJTn mrYA== X-Gm-Message-State: AJaThX7gIpLcclZr4Pzq4XPZ6QvWoW6xiInF5NH6jpiIjMB+CaNEqlKz /SpuoHMWruoVt7z6me0mHXFri1fm X-Google-Smtp-Source: AGs4zMasbTdww+DlZ0jY0kMG8nsm7SVoVZ28vNs3ToWm1+jnwKLxcuaWLo7OEK34c6T+1/9YP2WYwA== X-Received: by 10.36.209.2 with SMTP id w2mr8202364itg.130.1510945713598; Fri, 17 Nov 2017 11:08:33 -0800 (PST) Received: from mail-io0-f175.google.com (mail-io0-f175.google.com. [209.85.223.175]) by smtp.gmail.com with ESMTPSA id p17sm1477263iod.15.2017.11.17.11.08.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Nov 2017 11:08:33 -0800 (PST) Received: by mail-io0-f175.google.com with SMTP id i184so2370976ioa.0; Fri, 17 Nov 2017 11:08:33 -0800 (PST) X-Received: by 10.107.156.209 with SMTP id f200mr3764846ioe.226.1510945713354; Fri, 17 Nov 2017 11:08:33 -0800 (PST) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.2.165.150 with HTTP; Fri, 17 Nov 2017 11:08:32 -0800 (PST) In-Reply-To: <20171117093436.6wsrynphvcm6re4h@ivaldir.net> References: <201704152015.v3FKFiwZ006836@repo.freebsd.org> <20171117093436.6wsrynphvcm6re4h@ivaldir.net> From: Conrad Meyer Date: Fri, 17 Nov 2017 11:08:32 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r316980 - head/contrib/zstd/programs To: Baptiste Daroussin Cc: src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org, Allan Jude Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 19:16:55 -0000 On Fri, Nov 17, 2017 at 1:34 AM, Baptiste Daroussin wrot= e: > On Wed, Nov 15, 2017 at 07:38:13PM -0800, Conrad Meyer wrote: >> Please revert this change. >> >> First, it introduces the POLA-violating behavior that zstdcat deletes >> its source files. This is not how zcat/bzcat behaves. > > I have modified zstdcat to behave like zcat/bzcat. > > The commit you stated is exactly to ensure the zstd(1) command is behavin= g like > xz, gzip, etc (to the exception of zstdcat which was buggy) this commit i= s > needed to have those tools a drop-in replacement for other compression pr= ograms. > (which is necessary for example to have newsyslog being able to use zstd.= ) > > I committed a change needed in base and I will start a discussion with up= stream > > Best regards, > Bapt Hi Bapt, I don't think that's a good enough reason to differ from upstream. Furthermore, the change isn't documented. For compatibility with gzip/xz, you could simply add a new FreeBSD-specific zstd frontend with the behavior you want =E2=80=94 instead= of changing every other frontend. That way the behavior and documentation would match both the documentation we ship and the upstream documentation and behavior. No surprises for anyone. I really want to emphasize that *deleting user files when we claim we will not* is an awful design choice to make. I think this change should be reverted until at minimum our documentation is updated to inform users we do not --keep by default. (I think we should stay with upstream regardless, but if we're going to make a major change like this it MUST be documented.) Best, Conrad