Subject: Re: bug#62572: Bug#1058752: bug#62572: cp --no-clobber behavior has changed

From: Michael Stone <[email-masked]>
Date: Mon, 29 Jan 2024 11:44:57 -0500

On Mon, Jan 29, 2024 at 04:11:05PM +0000, Pádraig Brady wrote:
>>You've introduced a silent incompatibility and I'm trying to find some
>>way to make that clear. If upstream would provide a better solution I
>>would certainly use it. I have despaired of there being such since your
>>attitude thus far seems to be entirely dismissive of compatibility
>>concerns.
>
>That's a bit unfair.  The current upstream -n behavior is with a view
>to being _more_ compat across all systems.
>Now I agree this may not be worth it in this case,
>but it is a laudable goal.

You are saying that again without explicitly acknowledging that "being 
_more_ compat" in this case means "becoming _incompat_ with the vast 
majority of installed systems". IMO it could be reasonably phrased as 
"being more compatible across all systems in the long term when all 
existing legacy systems are gone", but the key here is that I read 
"_more_ compat across all systems" as dismissing the coreutils installed 
base as part of "all systems". I understand that may not be/have been 
the intent, but I also can't help feeling the way that I do when the 
benefits of compatability with freebsd are repeatedly emphasized while 
the costs of incompatibility with the coreutils installed base are 
dismissed with something along the lines of "we'll see what breaks". (If 
the costs of incompatibility are really that low in this case, why would 
compatability be a worthwhile goal in this case?)

I do wish that more users had noticed the change earlier and that we're 
fairly deep into a mess, but it's not always easy to see the impact of 
what seems like a relatively minor patch. I do appreciate that the new 
version printed some diagnostics when the change was triggered, as that 
certainly helped call attention to scripts which were impacted.

>With the above in place for the next coreutils release,
>then debian could remove its noisy patch.

I would certainly align with that, and the sooner the better to decrease 
the chances that different distributions handle this in different ways 
or we get to the point of having to release in an interim state. If you 
commit a final version I'll apply that patch if the next release isn't 
imminent.