Bug#735134: perl: rename(1) is ancient

[Niko Tyni]

[Don: Cc'ing you due to your participation in #304705. See below.]

On Mon, Jan 13, 2014 at 12:54:10AM +0100, Richard Hartmann wrote:
> Package: perl
> Version: 5.18.1-5
> Severity: normal
 
> the rename(1) which ships with perl is located in
> 
>   debian/rename
> 
> in the source package and stuck at a version from 1998:

I'm not sure this is a bug in itself. Besides, it was updated in 2002:

perl (5.8.0-8) unstable; urgency=low
  [...]
  * Add -f (--force) option to /usr/bin/rename (closes: #140746).
  * Add -n (--no-act) option to /usr/bin/rename (suggested by
    frederik at ugcs.caltech.edu).
  [...]
 -- Brendan O'Dea <bod at debian.org>  Sat, 24 Aug 2002 14:53:35 +1000


> CPAN[1] carries a version 1.8 from 2010, but the two do not seem to
> share history[2].

> [1] http://search.cpan.org/~pederst/rename/

> There is at least one competing version 0.20[3], which also does not
> share history[4].

> [3] https://metacpan.org/pod/release/RMBARKER/File-Rename-0.20/

> The former version seems to offer more features than the latter.

It looks like both have the same history up to eg/rename removal from the
Perl source in 2000. The File-Rename one probably has some more common
history and seems to be actively maintained. Dunno about any missing
features; I expect RBARKER would be receptive to requests about those.
(The PEDERST version actually seems rather bloated to me FWIW.)

However, I don't think we should update debian/rename but rather move
it to a separate package now there is an actual upstream with a test
suite et al.

I note that we really ship the script as /usr/bin/prename and manage
/usr/bin/rename with the alternatives system.  This was introduced due
to #304705 but turned out to be completely useless: the intention was to
offer the choice of /usr/bin/rename.ul from util-linux, but that didn't
work out because the command line syntax is incompatible (see #439935).

So the /usr/bin/rename syntax we've ended up with is very Perl specific
and I think we're stuck with that. I'm Cc'ing Don Armstrong though,
as he suggested using the alternatives system in #304705 and may have
something to add.

I suggest something like

- package libfile-rename-perl
- make it supply a better /usr/bin/rename with the alternatives system
- make the old one from the perl package issue warnings, Recommend 
  libfile-rename-perl for one release cycle
- scan build logs etc. for the warnings, file bugs to get as many
  affected packages as possible to depend on libfile-rename-perl
- remove the perl alternative and the perl -> libfile-rename-perl
  recommendation early in the next release cycle and see what's left
  that breaks
- disarm the alternatives system in libfile-rename-perl

We could also disarm the alternatives system from perl right away and
use diversions for the transition, but abusing the alternatives seems
easier as long as they are there, and it feels a bit safer to push the
upgrade code to the separate package.

(I do wonder if the end result is worth the trouble.)
-- 
Niko Tyni   ntyni at debian.org