[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



On Mon, 31 Jan 2022 at 10:11:19 +0000, Matthew Vernon wrote:
> There are two "rename" programs, one part of upstream util-linux "rename.ul"
> and one provided by the rename package "rename.pl"[0]

Almost!

The one in src:rename is installed as file-rename(1p), aka prename(1p)
via a symlink (you noted that this is the case on stable, but it's also
the case in unstable). /usr/share/doc/rename/examples/rename.pl is just
the core functionality of file-rename(1p), excluding CLI boilerplate
like displaying help in order to be a better/clearer example. There's
no rename.pl in PATH.

Other than that, you're correct.

Unfortunately, neither implementation has an upstream name other than
"rename". The file-rename naming is a Debian invention, with the rationale
that it comes from the File::Rename CPAN distribution (what we'd call
a source package). Similarly, the rename.ul naming is a Debian invention
to avoid colliding with File::Rename's rename.

> For a long time, Debian's "/usr/bin/rename" has been [file-rename] (via the
> alternatives system).

The history here is that perl.deb used to ship rename(1) as a Debian-specific
addition, based on a script eg/rename that was included in the Perl source
code before 2000.

https://bugs.debian.org/304705 was an earlier attempt to give users a
choice between util-linux rename and Perl rename via alternatives, which
is the reason the alternatives are there in the first place. However,
this was a wrong use of alternatives, leading to
https://bugs.debian.org/439935 and removal of the alternative.

When the Perl maintainers removed its implementation of rename(1),
since the alternatives were already there (left over from #304705), they
used the alternatives mechanism as a way to transition to the separate
implementation in src:rename.

Requests to ship util-linux rename(1) go back as far as at least
2004 (https://bugs.debian.org/228737).

> Assuming that's all correct, my feeling is that there is no particular
> reason for Debian's rename to stop being [file-rename], but that we should
> make rename.ul available to users who want it. I think the maintainer would
> be happy to move rename.ul into bsdextrautils (as /usr/bin/rename.ul)? Taking
> it out of essential, not considering it an alternative to [file-rename], and
> keeping it available for people who want it.

If the util-linux maintainer is OK with that, then I think that's probably
going to be the least-bad solution. It's unfortunate that Debian and other
distros have settled on incompatible rename implementations, but it has
happened, and now neither group of distributions can be compatible with
the other one without breaking compatibility with older versions of itself.

    smcv


Reply to: