[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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140202151231.go26...@urchin.earth.li
