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

[Dominic Hargreaves]

[CCing debian-devel to get feedback on a de facto 'standard' tool].

On Sat, Jan 18, 2014 at 03:34:29PM +0000, Dominic Hargreaves wrote:
> On Tue, Jan 14, 2014 at 12:59:04PM -0800, Don Armstrong wrote:
> > On Tue, 14 Jan 2014, Niko Tyni wrote:

> > > I suggest something like
> > > 
> > > - package libfile-rename-perl
> > > - make it supply a better /usr/bin/rename with the alternatives system
> 
> libfile-rename-perl is now on its way to NEW.
> 
> > > - make the old one from the perl package issue warnings, Recommend 
> > >   libfile-rename-perl for one release cycle
> > 
> > I don't know if this is actually necessary. We could just have perl
> > depend on libfile-rename-perl once we remove debian/rename. Or just keep
> > rename as it is currently. But I'm OK with either option so long as
> > /usr/bin/rename keeps the same syntax.
> 
> I think removing the rename from the Debian package is the best long-term
> option, otherwise we still end up carrying dead code around. The question
> of whether we carry around a Depends long-term rather depends on whether
> users generally consider rename a fundamental part of the perl package.
> It's certainly become quite a basic tools that I expect to see on Debian
> systems, but others may disagree. The alternative, of course, is for
> libfile-rename-perl to just be Standard, without any actual long-term
> dependencies.

So to summarise: for many years the perl package has provided
/usr/bin/rename, a stanalone utility implemented in perl. The issue is we
don't want to provide the utility from the perl package any more because
it's been added locally inside debian/ and is not being maintained. A
maintained version is available as a separate package, libfile-rename-perl.

The proposals on the table are:

1) Have perl Depend on libfile-rename-perl (and therefore have the
   latter become Priority: standard)
2) Make libfile-rename-perl be Standard, to match perl, without adding
   any dependencies.
3) Have perl Recommend libfile-rename-perl for one release cycle and then
   drop it
   - optionally with a warning being emitted by the built-in script
4) 2) + 3) combined.

Option 1 would imply that the utility is fundamentally a part of 
using perl, which since it's a standalone command line program which
happens to be written in perl, seems wrong.

Option 2 is my preferred option because it seems like the 'least surprise'
option. 4) can be considered a mostly-harmless enhancement to that,
although adding warnings could be irritating or harmful in some
circumstances.

Any further thoughts or alternative options?

Cheers,
Dominic.