On 27/01/2024 16:02, Michael Stone wrote:
On Sat, Jan 27, 2024 at 02:00:14PM +0100, Sven Joachim wrote:
Package: coreutils
Version: 9.4-3+b1
,----
| $ cp -n /bin/true tmp
| cp: warning: behavior of -n is non-portable and may change in future; use
--update=none instead
`----
The advice to use the --update=none option is highly questionable,
because this option is even less portable than -n. It is not available
in coreutils older than 9.3 or in other cp implementations.
There is no alternative that I can see. I didn't create this situation,
it was created upstream. You can continue to use -n and ignore the
warning, but in future if debian stops patching -n to behave the way it
always has in order to match upstream, stuff will break. If debian keeps
patching -n, then then anything you write in debian will be depending on
behavior that differs in other distributions and will break everywhere
else (except older versions of those distributions). It's a mess.
This warning isn't for debian developers of existing packages, because
debian is maintaining compatibility (at least for now); you'll see a
warning message but the actual behavior hasn't changed and won't change
in debian without some coordination with affected packages. But for
developers with *new* upstream code that uses -n, which behavior does
the code expect? There are now two answers and *the only solution is to
not use -n*; it's not possible to simply file bugs with packages and fix
it once, because this is an ongoing incompatibility. I understand that
the messages are somewhat obnoxious, but my attempt to address the
situation upstream instead failed.
That is a very aggressive deprecation.
IMHO it would have been better for debian to have -n behave
like it did previously and (silently) skip files and not set an error exit
status.
If it was a mess, this is a mess squared.
I guess this forces our hand a bit.
I'll address upstream...
