Bug#735134: perl: rename(1) is ancient
Dominic Hargreaves
dom at earth.li
Sat Jan 18 15:34:29 UTC 2014
On Tue, Jan 14, 2014 at 12:59:04PM -0800, Don Armstrong wrote:
> On Tue, 14 Jan 2014, Niko Tyni wrote:
> > 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 long as the base command line syntax is compatible, then there isn't
> really a problem with using alternatives to support them both. [I have
> to admit that my advice in #304705 to support alternatives was naïve, as
> alternatives need to share a common command line syntax.]
>
> > 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
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.
Cheers,
Dominic.
More information about the Perl-maintainers
mailing list