Re: Bug#735134: perl: rename(1) is ancient
On Mon, May 05, 2014 at 03:51:06PM +0100, Dominic Hargreaves wrote:
> On Sun, Feb 02, 2014 at 03:12:32PM +0000, Dominic Hargreaves wrote:
> > [CCing debian-devel to get feedback on a de facto 'standard' tool].
> > 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.
>
> Based on all the comments, I am proceeding to:
>
> 1) Make 'rename' (as it has now been renamed, from libfile-rename-perl)
> Priority: standard
This was done.
> 2) Add a Recommends on rename to the perl package for a transitional period
This was done.
> 3) Submit a new lintian check for things which use rename or prename in
> build scripts, advising of changes needed.
This was... shall we say delayed. I attempted to identify packages
to fix through codesearch.debian.net and through lintian, but the
number of different ways one could call such a generic-named command
made this impractical and/or unreliable.
My new plan is to add a deprecation message to the built-in rename
(printing a message to standard error as soon as it runs) advising
people to install the separate 'rename' package.
> 4) Wait until vitually all packages have been fixed and then remove
> prename from the perl package
My new plan is to then remove prename from the perl package after the
release of stretch (and to also drop the Recommends from the perl
package at about the same time).
There is always the chance that people won't read their build logs
to see this being used in Debian packaging scripts, but I don't believe
the number of instances is so high as to make the breakage intolerable.
Thanks,
Dominic.
Reply to: