Re: Bug#735134: perl: rename(1) is ancient
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].
>
> 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.
Based on all the comments, I am proceeding to:
1) Make 'rename' (as it has now been renamed, from libfile-rename-perl)
Priority: standard
2) Add a Recommends on rename to the perl package for a transitional period
3) Submit a new lintian check for things which use rename or prename in
build scripts, advising of changes needed.
4) Wait until vitually all packages have been fixed and then remove
prename from the perl package
Cheers,
Dominic.
Reply to: