Bug#1003653: Revision of removal of rename.ul from package util-linux

2022-01-25 Thread Chris Hofstaedtler
Hi,

* Sean Whitton  [220125 00:06]:
> On Mon 24 Jan 2022 at 11:33AM +01, Chris Hofstaedtler wrote:
> 
> > For context, the idea is that /usr/bin/rename should become
> > src:util-linux' rename implementation.
> 
> That seems likely to break a great many scripts, though?
> 
> Perhaps we should ship them both under a name other than
> /usr/bin/rename, such that people are prompted to update their scripts
> to choose one, or create their own symlink?

Then all of this is a completely pointless exercise. Either we break
them, or it is favorable to keeping the way things are:

A very valid way of closing this discussion is saying "our
(Perl) /usr/bin/rename is great, people should use that".

Chris



Bug#1003653: Revision of removal of rename.ul from package util-linux

2022-01-25 Thread Dirk Kostrewa

On 25/01/2022 09:16, Chris Hofstaedtler wrote:

Hi,

* Sean Whitton  [220125 00:06]:

On Mon 24 Jan 2022 at 11:33AM +01, Chris Hofstaedtler wrote:


For context, the idea is that /usr/bin/rename should become
src:util-linux' rename implementation.

That seems likely to break a great many scripts, though?

Perhaps we should ship them both under a name other than
/usr/bin/rename, such that people are prompted to update their scripts
to choose one, or create their own symlink?

Then all of this is a completely pointless exercise. Either we break
them, or it is favorable to keeping the way things are:

A very valid way of closing this discussion is saying "our
(Perl) /usr/bin/rename is great, people should use that".

Chris

Both rename programs are around for a long time and have their use 
cases, and apparently, there are users who rely on one or the other.


Say, the bsdutils package provides "rename.ul", and the perl rename 
package provides "rename.pl". Debian's alternatives system could then 
make each of them available as "/usr/bin/rename". If both get installed, 
the user could be prompted to choose a default "rename".


Would this apparently simple solution really create any problems?

Dirk.



Bug#1003653: Revision of removal of rename.ul from package util-linux

2022-01-25 Thread Russ Allbery
Dirk Kostrewa  writes:

> Say, the bsdutils package provides "rename.ul", and the perl rename
> package provides "rename.pl". Debian's alternatives system could then
> make each of them available as "/usr/bin/rename". If both get installed,
> the user could be prompted to choose a default "rename".

> Would this apparently simple solution really create any problems?

Alternatives cannot be used in this case because the command-line syntax
is entirely different.  One of the requirements we use to determine
whether something can be an alternative for another program is whether
it's (mostly) a drop-in replacement; if, in other words, a user running
the program from the command-line will roughly the same behavior in simple
use cases regardless of which alternative they pick.  This is important
since otherwise it would be impossible to write shell scripts, aliases,
etc. that use the alternative name without knowing which alternative was
chosen on any given system (which defeats the point of alternatives).

We can tolerate some minor disagreement (missing non-core features,
slightly different command-line flags, etc.), but in the case of rename,
the syntax is just totally different.  The Perl rename will take the
replacement string in the util-linux syntax as a file to operate on (and
thus will probably fail), and the util-linux rename will take the Perl
expression as the string to replace and the first file name argument as
the replacement string, and thus will probably do nothing.

-- 
Russ Allbery (r...@debian.org)