Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 17 Nov 2017 11:08:32 -0800
From:      Conrad Meyer <cem@freebsd.org>
To:        Baptiste Daroussin <bapt@freebsd.org>
Cc:        src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org,  svn-src-head@freebsd.org, Allan Jude <allanjude@freebsd.org>
Subject:   Re: svn commit: r316980 - head/contrib/zstd/programs
Message-ID:  <CAG6CVpWJK9uKWk4o5%2BDR=ppnEQi2Cu=2CHA7odDOJJDjDQyuVg@mail.gmail.com>
In-Reply-To: <20171117093436.6wsrynphvcm6re4h@ivaldir.net>
References:  <201704152015.v3FKFiwZ006836@repo.freebsd.org> <CAG6CVpWxxUuT13NL%2B0LbEDW3N91i4-imsXUBrv1jiTcihs25KQ@mail.gmail.com> <20171117093436.6wsrynphvcm6re4h@ivaldir.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 17, 2017 at 1:34 AM, Baptiste Daroussin <bapt@freebsd.org> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG6CVpWJK9uKWk4o5%2BDR=ppnEQi2Cu=2CHA7odDOJJDjDQyuVg>