Bug#1003653: Revision of removal of rename.ul from package util-linux

[Sean Whitton]

Hello Chris,

On Mon 24 Jan 2022 at 11:33AM +01, Chris Hofstaedtler wrote:

> For context, the idea is that /usr/bin/rename should become
> src:util-linux' rename implementation.

That seems likely to break a great many scripts, though?

Perhaps we should ship them both under a name other than
/usr/bin/rename, such that people are prompted to update their scripts
to choose one, or create their own symlink?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1003653: Revision of removal of rename.ul from package util-linux

[Russ Allbery]

Christoph Berg  writes:

> We were discussing the bug in last week's tech-ctte meeting, and the
> gist of the discussion was that, in a ideal world, Debian would be
> shipping the util-linux version as /usr/bin/rename to match what other
> distributions are shipping, but that since we have been shipping the
> Perl rename for the past 20 years, a proper transition would be very
> hard.

I understand the appeal of this for cross-distribution compatibility, but
we haven't been compatible with other distributions for a very long time
and there haven't seem to have been that many complaints.  Even the
request that set off this discussion was, if I recall correctly, only
about getting access to the util-linux version, not about changing the
default /usr/bin/rename.

Balancing against this is the fact that the Perl rename, while a bit more
complicated to use, is significantly more useful.  The util-linux rename
can only do simple substring replacements, not even regexes (and at least
in my experience a simple s/// expression is the most common use case for
rename).

Neither version is a strict subset of the other (the util-linux
--interactive and --symlink arguments don't appear to have equivalents in
the Perl version), but the Perl version also supports -0 so that it can be
used safely with find/xargs.

It's unfortunate that the command-line syntax for the two programs is
different in such a way as to make it impossible to merge them and write
one program that supports the syntax of both.

-- 
Russ Allbery (r...@debian.org)  

Bug#1003653: Revision of removal of rename.ul from package util-linux

[Zack Weinberg]

As an end user I wish to register an objection to any solution to this bug that 
makes it impossible for me to install a Debian system where, out of the box, 
"rename" in the default PATH is the Perl rename.  This is what my fingers 
expect, and what dozens of non-packaged scripts rely on.

(I say "the default PATH" and "out of the box" because I _can_ always put a 
symlink in $HOME/.local/bin or /usr/local/bin, regardless of what packages do, 
but that's an extra step that may not be tracked by configuration management 
and may not apply to all processes.)

I recognize that there are people coming to Debian from environments where 
there is precisely the opposite expectation, but I think backward compatibility 
with the environment Debian has provided for many years is, in this case, more 
important.

zw

Bug#1003653: Revision of removal of rename.ul from package util-linux

[Chris Hofstaedtler]

* Sean Whitton  [220124 05:56]:
> On Sun 23 Jan 2022 at 10:27PM +01, Christoph Berg wrote:
> > Re: Sean Whitton
> >> On Sun 23 Jan 2022 at 10:04PM +01, Chris Hofstaedtler wrote:
> >> > I guess the best thing would be to introduce a new binary package,
> >> > but I am out of ideas on naming it. Open for ideas here.
> >>
> >> util-linux-extra?
> >
> > If it's about rename only, "rename-ul" or even "rename.ul"?
> >
> > I guess it should also contain the historical name as a symlink.
> >
> > Christoph
> 
> Well, Chris mentioned wanting to transition some other things out of the
> essential package in addition to this one.  Also, the ftp team would not
> love the idea of a single-script package.

I think this will mostly depend on what src:rename will/should do
(+CC: Debian Perl Group, Dominic Hargreaves).

For context, the idea is that /usr/bin/rename should become
src:util-linux' rename implementation. As was found in the past,
this is not possible using alternatives. As the util-linux
maintainer, I would also prefer to not having alternatives.

If the rename binary package drops /usr/bin/rename, rename.ul(*) can
start installing that, and conflict on old versions of rename.
Or, to make this transition more clear to users:
 - src:rename could drop /usr/bin/rename AND rename its binary package to
   file-rename (?) or prename (?)
 - rename.ul could Conflict: rename indefinitely

Chris

(*) "working title"