Bug#1003653: Revision of removal of rename.ul from package util-linux
Hi,
On Mon, Jan 31, 2022 at 10:11:19AM +0000, Matthew Vernon wrote:
> The two renames have substantially different CLI syntax, making them
> unsuitable for an alternatives arrangement
I think that much of the discussion has taken this point for granted,
but it is one of the aspects that the submitter takes issue with. I
question: Is it really the case that incompatible interfaces make a tool
unsuitable for alternatives?
Maybe we should consider some similar cases? There are two that come to
my mind.
python3 is sufficiently different to python2 that it was deemed unfit to
fill the name /usr/bin/python in general. Yet, we have packages
python-is-python2 and python-is-python3. This is not using alternatives,
but it is an example where it is useful to allow a name to be taken by
different tools with substantially different interfaces. At the same
time, we have a policy that nothing in Debian may make use of
/usr/bin/python to allow this flexibility.
Another is renames. When nodejs was first introduced, it was denied
using the name /usr/bin/node. That other use of the name has since been
faded out and the name has been given to nodejs. Again, not using
alternatives, but a substantially changed interface.
I wasn't able to find cases where alternatives were used with
substantial interface differences. Often times it seems to be used for
changing the implementation of some command which is used by other
packages (popular example: awk).
Another way to look at it is figuring what uses /usr/bin/rename.
Searching for it is not easy as the term is so generic. I've found some
uses.
All of these use the file-rename syntax:
https://sources.debian.org/src/duplicity/0.8.21-1/testing/manual/run-coverage.sh/?hl=58#L58
https://sources.debian.org/src/gdcm/3.0.10-1/Utilities/gdcmjpeg/dcmtk.sh/?hl=18#L18
https://sources.debian.org/src/firebird3.0/3.0.8.33535.ds4-1/debian/make_packages.sh/?hl=185#L185
https://sources.debian.org/src/caveexpress/2.5.2-1/contrib/scripts/fontmerge.sh/?hl=22#L22
https://sources.debian.org/src/caveexpress/2.5.2-1/contrib/scripts/convert-layer.sh/?hl=63#L63
Most of them seem to be utility scripts for development.
A particular entertaining one is this:
https://sources.debian.org/src/rclone-browser/1.8.0-1.2/scripts/release_AppImage.sh/?hl=150#L150
It uses both syntaxes in the same source.
Beyond that, no package depends on rename and only xymon suggests it.
So maybe changing /usr/bin/rename to something else is not the worst of
options, but using alternatives for that task likely is the wrong tool.
As such, it does not seem too absurd to add some policy forbidding the
use of /usr/bin/rename (deferring in-archive users to
implementation-specific names). Once that is in place, the decision of
what /usr/bin/rename points to can be deferred to administrators (which
seems to be what the ctte filing is about) by some means other than
alternatives. Perhaps, we need file-is-file-rename and
file-is-rename.ul?
In any case, what I sketched here is a larger transition that shouldn't
be dumped on the util-linux maintainer somehow.
Dirk, would you be interested in working on a transition plan?
> #966468 & #982944 asked for rename.ul to return (though the latter rather
> confuses the removal vs alternatives issue)
I think it is relatively uncontroversial to return rename.ul in some
non-essential form. Chris vaguely offered including it in bsdextrautils
(without a clear plan on how). How about adding rename as
/usr/bin/rename.ul to bsdextrautils without participating in
alternatives? Would you, Chris, agree to that? I think doing so would
please some users and reduce the conflict. Those people could then ln -s
/usr/bin/rename.ul /usr/local/bin/rename on their systems. It may not be
as convenient as installing a package or using update-alternatives, but
it isn't that hard either.
In any case, I fear we may run counter to §6.3.5 (no detailed design
work). It seems pretty clear that the issue is in large part a
communication issue. As such, maybe we can wind this down already?
Helmut
Reply to: