svn commit: r365643 - head/bin/cp

[Kyle Evans]

Correct- we're good now. Thanks!

On Tue, Sep 22, 2020 at 9:59 PM Alan Somers <asomers at freebsd.org> wrote:
>
> Go ahead and commit.  Consider it reviewed by me.  And if I understand correctly, this commit means there's no need for a special updating procedure, right?
>
> On Tue, Sep 22, 2020 at 6:55 PM Warner Losh <imp at bsdimp.com> wrote:
>>
>>
>>
>> On Tue, Sep 22, 2020 at 5:17 PM Kyle Evans <kevans at freebsd.org> wrote:
>>>
>>> On Tue, Sep 22, 2020, 17:02 Warner Losh <imp at bsdimp.com> wrote:
>>>>
>>>>
>>>>
>>>> On Tue, Sep 22, 2020 at 3:55 PM Kyle Evans <kevans at freebsd.org> wrote:
>>>>>
>>>>> On Tue, Sep 22, 2020 at 4:53 PM Ian Lepore <ian at freebsd.org> wrote:
>>>>> >
>>>>> > On Tue, 2020-09-22 at 15:50 -0600, Warner Losh wrote:
>>>>> > > I think it's a great leap sideways, but I've done cp /dev/null foo to
>>>>> > > clear
>>>>> > > it out for 35 years now... It's why it feels like a workaround.
>>>>> > >
>>>>> > > Though it is a legit optimization, no matter the feelings. As for
>>>>> > > clearer,
>>>>> > > I'm less sure since then I have to remember what the : operator does.
>>>>> > >
>>>>> > > Warner
>>>>> > >
>>>>> >
>>>>> > For me, :> is idiomatic (but ugly).
>>>>> >
>>>>> > On the other hand, the cp /dev/null had a nice dogfooding aspect to
>>>>> > it... when we broke cp by accident, its use in the build system was the
>>>>> > first alarm to go off.
>>>>> >
>>>>> > --Ian
>>>>> >
>>>>>
>>>>> To be honest, this is a case that really should be covered by
>>>>> regression tests somewhere.
>>>>
>>>>
>>>> It should (but isn't yet).
>>>>
>>>> Ian is right for old-school FreeBSD thinking. In that thinking the build system should use an eclectic mix of tools to act as a fire-wall against accidental breakage.
>>>>
>>>> Complete, effective, test suites give much better coverage... if they are run...
>>>>
>>>> So until we run tests frequently, with loud regression squawking that's as effective as build breakage, I tend to fall in the 'all of the above' camp until that's in place... :)
>>>>
>>>> Warner
>>>>
>>>> P.S. though not, if I suppose, if it means that we're slowing down the regression coverage uptake...
>>>
>>>
>>> --
>>>
>>> The test build was fine, please confirm if I can commit it or if someone else would like to write the UPDATING notice or start bootstrapping cp on systems that were affected. I'm not comfortable with not taking any path at all here, but this is a lot of friction for a small mechanical change to ease the pain.
>>
>>
>> Sorry if I wasn't clear: I'm not objecting to the quick mechanical change so much as complaining that I wish we had better test coverage. Don't let that stop you from doing what's right (or I can if you'd like).
>>
>> Warner