bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Michael Stone
Subject: bug#62572: Bug#1058752: bug#62572: cp --no-clobber behavior has changed
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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]