Bug#735134: perl: rename(1) is ancient
dom at earth.li
Sun Feb 2 15:12:32 UTC 2014
[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
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
3) Have perl Recommend libfile-rename-perl for one release cycle and then
- 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
Any further thoughts or alternative options?
More information about the Perl-maintainers