Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

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

121 views
Skip to first unread message

Dirk Kostrewa

unread,
Jan 13, 2022, 5:10:04 AM1/13/22
to

Package: tech-ctte
Severity: normal

Dear Technical Committee,

the program rename.ul is a bulk file renaming program with a versatile and simple syntax. It is part of the public software util-linux on kernel.org https://www.kernel.org/pub/linux/utils/util-linux/ and is probably present in every Linux distribution including Debian for at least 14 years up to "Buster".

A user requested in Debian bug report #926637 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926637) to include rename.ul in Debian's alternatives system. The package maintainer replied:

"The util-linux rename command does not implement the same (command line)
interface as the alternative(s) does, so it is not policy compliant to
add it as an alternative."

As a result, the maintainer completely removed rename.ul from the package util-linux without providing any further reference to this Debian policy.

Another Debian bug report #966468 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966468) to provide rename.ul in util-linux again was set to "WONTFIX" without giving any further reason.

In Debian bug report #982944 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982944 users complained about the arbitrary removal of rename.ul from util-linux and argued:

- no Debian policy could be found for the removal of rename.ul from util-linux based on interface differences in the alternatives system

- interface differences are part of the alternatives system, and program examples were given

- removal of rename.ul broke workflows existing for decades, including a scientific workflow at a university

To summarize: the program rename.ul of the util-linux package has been around for decades in Debian and probably every other Linux distribution. The maintainer removed this program referring to a Debian policy which seems not to exist. Furthermore, differences in program interfaces in Debian's alternative system can be found in other program examples and are no reason to remove such a well-established program. Thus, the removal of rename.ul from the util-linux package appears to be both unnecessary and arbitrary.

Since the maintainer did not respond to any of the user arguments in the above bug reports, I kindly request the technical committee to revise the removal of rename.ul from the package util-linux, hoping that this removal will be reversed.

Kind regards,

Dirk Kostrewa.

Christoph Berg

unread,
Jan 13, 2022, 6:00:08 AM1/13/22
to
> A user requested in Debian bug report #926637
> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926637) to include
> rename.ul in Debian's alternatives system. The package maintainer replied:
>
> "The util-linux rename command does not implement the same (command line)
> interface as the alternative(s) does, so it is not policy compliant to
> add it as an alternative."
>
> As a result, the maintainer completely removed rename.ul from the package
> util-linux without providing any further reference to this Debian policy.

That's a pretty surprising resolution of a bug asking to be able to
use "rename" more easily.

> Since the maintainer did not respond to any of the user arguments in the
> above bug reports, I kindly request the technical committee to revise the
> removal of rename.ul from the package util-linux, hoping that this removal
> will be reversed.

The removal happened in util-linux (2.35.2-5) on 25 Jun 2020, so it's
already in stable (bullseye) which has 2.36.1-8. Not sure if fixing
this now will unbreak any harm that has already been done, given that
the bullseye release was already half a year ago.

Christoph

Chris Hofstaedtler

unread,
Jan 21, 2022, 11:50:04 AM1/21/22
to
Hi,

I am the current src:util-linux maintainer and have become aware of
this bug by pure coincidence.

* Christoph Berg <my...@debian.org> [220121 16:28]:
> > A user requested in Debian bug report #926637
> > (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926637) to include
> > rename.ul in Debian's alternatives system. The package maintainer replied:
> >
> > "The util-linux rename command does not implement the same (command line)
> > interface as the alternative(s) does, so it is not policy compliant to
> > add it as an alternative."
> >
> > As a result, the maintainer completely removed rename.ul from the package
> > util-linux without providing any further reference to this Debian policy.
>
> That's a pretty surprising resolution of a bug asking to be able to
> use "rename" more easily.

I have now asked about the history of rename, and was pointed to
#735134, which moved rename from src:perl to a new source package
and out of build-essential.

You can find the history in there, and by people that know more
about the different rename implementations, the claim that the
implementations are incompatible (or at least, not compatible).

I see absolutely zero point in shipping a program under a
non-default name in an essential package, which apparently only
very few users ever knew about.

If the util-linux rename should be made easier to use, then it
should become the one and only provider of /usr/bin/rename, and it
should not be in an essential package.

Generally speaking, the essential packages built by util-linux
install lots of things they should not. My longer term plan is to
reduce that, but as you can guess, this will take time.

I guess it would be possible for one of the non-essential
src:util-linux binary packages to take over /usr/bin/rename in a
coordinated way from src:rename, but I do not know how attached
people are to the existing /usr/bin/rename.

Side note: src:rename installs /usr/bin/rename using
update-alternatives, but no other package participates in this
alternative. I guess this is a transition leftover.

Chris

Russ Allbery

unread,
Jan 21, 2022, 12:20:04 PM1/21/22
to
Chris Hofstaedtler <ze...@debian.org> writes:

> If the util-linux rename should be made easier to use, then it should
> become the one and only provider of /usr/bin/rename, and it should not
> be in an essential package.

The two programs are very, very different, and I suspect the util-linux
version would not be suitable for what /usr/bin/rename is currently used
for inside Debian.

For those who aren't familiar with the history of this, the Perl version
which is currently installed as /usr/bin/rename takes argibrary Perl code
applies it to each file name to come up with the new file name. It
doesn't even have to be a regular expression; it can be a tiny Perl
program (and I have used it that way before). The util-linux rename only
does simple string substitution and has a completely different command
line syntax (it takes two strings as its first two arguments and then a
list of files, whereas the Perl rename takes a block of Perl code and then
a list of files).

They perform somewhat similar conceptual functions, but they're really
entirely different and incompatible programs that unfortunately for a
variety of historical reasons have ended up with the same name, not
versions of the same basic tool.

--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>

Chris Hofstaedtler

unread,
Jan 21, 2022, 7:30:03 PM1/21/22
to
* Russ Allbery <r...@debian.org> [220121 18:11]:
> Chris Hofstaedtler <ze...@debian.org> writes:
>
> > If the util-linux rename should be made easier to use, then it should
> > become the one and only provider of /usr/bin/rename, and it should not
> > be in an essential package.
>
> The two programs are very, very different, and I suspect the util-linux
> version would not be suitable for what /usr/bin/rename is currently used
> for inside Debian.

I understand the perl group maintainer scripts switched to using the
/usr/bin/file-rename name. We could investigate rdeps of rename and
see what they use, and/or change them.

> [valuable history]

> They perform somewhat similar conceptual functions, but they're really
> entirely different and incompatible programs that unfortunately for a
> variety of historical reasons have ended up with the same name, not
> versions of the same basic tool.

Yeah. We could put an end to that, if we want.

Chris

Don Armstrong

unread,
Jan 22, 2022, 2:10:03 AM1/22/22
to
On Sat, 22 Jan 2022, Chris Hofstaedtler wrote:
> * Russ Allbery <r...@debian.org> [220121 18:11]:
> > Chris Hofstaedtler <ze...@debian.org> writes:
> >
> > > If the util-linux rename should be made easier to use, then it should
> > > become the one and only provider of /usr/bin/rename, and it should not
> > > be in an essential package.
> >
> > The two programs are very, very different, and I suspect the util-linux
> > version would not be suitable for what /usr/bin/rename is currently used
> > for inside Debian.
>
> I understand the perl group maintainer scripts switched to using the
> /usr/bin/file-rename name. We could investigate rdeps of rename and
> see what they use, and/or change them.

This problem goes beyond reverse dependencies; there are also a
not-insignificant number of user scripts which on Debian expect
/usr/bin/rename to be the perl version (and probably a similar number on
other distributions which expect the opposite).

Not impossible to change, of course, but an ideal transition would avoid
breaking currently working scripts and installs.

--
Don Armstrong https://www.donarmstrong.com

After the first battle of Sto Lat, I formulated a policy which has
stood me in good stead in other battles. It is this: if an enemy has
an impregnable stronghold, see he stays there.
-- Terry Pratchett _Jingo_ p265

Christoph Berg

unread,
Jan 23, 2022, 4:00:04 PM1/23/22
to
Re: Don Armstrong
> > I understand the perl group maintainer scripts switched to using the
> > /usr/bin/file-rename name. We could investigate rdeps of rename and
> > see what they use, and/or change them.
>
> This problem goes beyond reverse dependencies; there are also a
> not-insignificant number of user scripts which on Debian expect
> /usr/bin/rename to be the perl version (and probably a similar number on
> other distributions which expect the opposite).
>
> Not impossible to change, of course, but an ideal transition would avoid
> breaking currently working scripts and installs.

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. Especially in the light that this is an end-user tool and not
something we can control by a MBF and a lot of patches.

Unfortunately the current defaults seem to be that we have neither,
none of my systems has any "rename" command. OTOH that might indicate
there's a head-start on a transition introducing u-l's rename as
/usr/bin/rename.

Chris, would u-l be willing to reintroduce rename, or do you rather
want to reduce the number of commands?

Maybe if alternatives are not the correct tool, moving the u-l rename
to a separate package, and conflicting with the perl rename is better?
(Still ugly, but the situation isn't ideal.)

Christoph

Chris Hofstaedtler

unread,
Jan 23, 2022, 4:10:04 PM1/23/22
to
* Christoph Berg <my...@debian.org> [220123 21:51]:
> Re: Don Armstrong
[..]
> > Not impossible to change, of course, but an ideal transition would avoid
> > breaking currently working scripts and installs.
>
> 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. Especially in the light that this is an end-user tool and not
> something we can control by a MBF and a lot of patches.

Yeah. I was thinking we could ship *one* release without a
/usr/bin/rename at all. Not sure if that is a good idea.

> Unfortunately the current defaults seem to be that we have neither,
> none of my systems has any "rename" command. OTOH that might indicate
> there's a head-start on a transition introducing u-l's rename as
> /usr/bin/rename.
>
> Chris, would u-l be willing to reintroduce rename, or do you rather
> want to reduce the number of commands?
>
> Maybe if alternatives are not the correct tool, moving the u-l rename
> to a separate package, and conflicting with the perl rename is better?
> (Still ugly, but the situation isn't ideal.)

I believe using alternatives would introduce an RC bug.

I was hoping we could put util-linux' rename into the
"bsdextrautils" binary package, which has utilities like write, col,
etc; to avoid putting it into an Essentials: yes package, and to
avoid a new binary package. However, picking bsdextrautils seems
... maybe not ideal if it should Conflict with rename.

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.

Chris

Christoph Berg

unread,
Jan 23, 2022, 4:40:03 PM1/23/22
to
Re: Sean Whitton
> Hello,
>
> 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

Chris Hofstaedtler

unread,
Jan 24, 2022, 5:40:03 AM1/24/22
to
* Sean Whitton <spwh...@spwhitton.name> [220124 05:56]:
> On Sun 23 Jan 2022 at 10:27PM +01, Christoph Berg wrote:
> > Re: Sean Whitton
> 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"

Zack Weinberg

unread,
Jan 24, 2022, 10:40:09 AM1/24/22
to
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

Russ Allbery

unread,
Jan 24, 2022, 12:20:03 PM1/24/22
to
Christoph Berg <my...@debian.org> 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.

Chris Hofstaedtler

unread,
Jan 25, 2022, 3:30:03 AM1/25/22
to
Hi,

* Sean Whitton <spwh...@spwhitton.name> [220125 00:06]:
> 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?

Then all of this is a completely pointless exercise. Either we break
them, or it is favorable to keeping the way things are:

A very valid way of closing this discussion is saying "our
(Perl) /usr/bin/rename is great, people should use that".

Chris

Dirk Kostrewa

unread,
Jan 25, 2022, 5:00:04 AM1/25/22
to
Both rename programs are around for a long time and have their use
cases, and apparently, there are users who rely on one or the other.

Say, the bsdutils package provides "rename.ul", and the perl rename
package provides "rename.pl". Debian's alternatives system could then
make each of them available as "/usr/bin/rename". If both get installed,
the user could be prompted to choose a default "rename".

Would this apparently simple solution really create any problems?

Dirk.

Russ Allbery

unread,
Jan 25, 2022, 11:40:03 AM1/25/22
to
Dirk Kostrewa <kost...@genzentrum.lmu.de> writes:

> Say, the bsdutils package provides "rename.ul", and the perl rename
> package provides "rename.pl". Debian's alternatives system could then
> make each of them available as "/usr/bin/rename". If both get installed,
> the user could be prompted to choose a default "rename".

> Would this apparently simple solution really create any problems?

Alternatives cannot be used in this case because the command-line syntax
is entirely different. One of the requirements we use to determine
whether something can be an alternative for another program is whether
it's (mostly) a drop-in replacement; if, in other words, a user running
the program from the command-line will roughly the same behavior in simple
use cases regardless of which alternative they pick. This is important
since otherwise it would be impossible to write shell scripts, aliases,
etc. that use the alternative name without knowing which alternative was
chosen on any given system (which defeats the point of alternatives).

We can tolerate some minor disagreement (missing non-core features,
slightly different command-line flags, etc.), but in the case of rename,
the syntax is just totally different. The Perl rename will take the
replacement string in the util-linux syntax as a file to operate on (and
thus will probably fail), and the util-linux rename will take the Perl
expression as the string to replace and the first file name argument as
the replacement string, and thus will probably do nothing.

Matthew Vernon

unread,
Jan 31, 2022, 5:40:03 AM1/31/22
to
Hi,

Having joined the committee, I thought it best to try and get up to
speed on this issue. Is my summary correct?

--begin

There are two "rename" programs, one part of upstream util-linux
"rename.ul" and one provided by the rename package "rename.pl"[0]

For a long time, Debian's "/usr/bin/rename" has been rename.pl (via the
alternatives system).

rename.ul is rename in some other distributions(RedHat; et al?)

The two renames have substantially different CLI syntax, making them
unsuitable for an alternatives arrangement

#926637 asked for rename.ul to become a rename alternative; the
maintainer explained why it was not a suitable alternative to rename.pl;
they then stopped shipping rename.ul entirely in 2.35.2-5

#966468 & #982944 asked for rename.ul to return (though the latter
rather confuses the removal vs alternatives issue)

None of the above bugs was linked with this TC bug (it would be normal
to block them on this bug), which unfortunately meant the maintainer
wasn't notified as early as would have been ideal

The maintainer's view is that there is too little value to having
rename.ul on a system in a place where you would not expect it to be;
and that further this even more strongly not be done in an "essential"
package that is installed everywhere.

--end

Assuming that's all correct, my feeling is that there is no particular
reason for Debian's rename to stop being rename.pl, 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 rename.pl, and keeping it available for people who want it.

Regards,

Matthew

[0] called file-rename on my stable system.

Simon McVittie

unread,
Jan 31, 2022, 6:40:04 AM1/31/22
to
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

Helmut Grohne

unread,
Jan 31, 2022, 11:20:03 AM1/31/22
to
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

Chris Hofstaedtler

unread,
Jan 31, 2022, 3:50:04 PM1/31/22
to
Hello Helmut,

Thank you for the very detailed research (which I have removed
in my reply below).

* Helmut Grohne <hel...@subdivi.de> [220131 17:09]:
> > #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.

With conflict I assume you mean the Conflicts relationship on the
involved packages.
From a technical perspective: sure, that could be done. I also agree
it avoids new relationships on the involved packages.

> 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.

I believe we (as a distro) should make a choice what /usr/bin/rename
should be, and ship -that-. Today this is prename, with an aborted
effort to make rename.ul possible instead. Given this previous
effort, and some earlier discussion here, I think it is valid to say
"/usr/bin/rename should be rename.ul" - but then it should be that,
and prename should be prename.
Otherwise I would like to keep the status quo: our choice for
/usr/bin/rename is prename.

There are a number of very good "distribution builders" out there,
plus a number of distributions which seem to subscribe to "ship
everything that exists".
I however believe that Debian should make choices, for our users and
in their interest. Shipping both (or maybe all rename-like tools)
and having that user-configurable is IMO not a good technical choice
and IMO also not in the interest of the larger community.

It appears "we" cannot make up our mind about this very small
utility. Why should we delegate this to our users then? If they are
interested, they will sink even more time into it and maybe create a
configuration that possibly causes problems in the future.

Best,
Chris

Helmut Grohne

unread,
Jan 31, 2022, 4:10:03 PM1/31/22
to
Hi Chris,

On Mon, Jan 31, 2022 at 09:39:40PM +0100, Chris Hofstaedtler wrote:
> * Helmut Grohne <hel...@subdivi.de> [220131 17:09]:
> > > #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.
>
> With conflict I assume you mean the Conflicts relationship on the
> involved packages.

I see how you can come to this interpretation, but it is not what I
meant to say. It is true that the proposal avoids the need for a
Conflicts declaration on the package metadata level, but here I was
referring to the differing opinions on how util-linux' rename
implementation should be packaged as "conflict". My thinking was that by
providing the requested tool as an installable executable under some
(non-standard) path, you solve half of the practical problems.

> I believe we (as a distro) should make a choice what /usr/bin/rename
> should be, and ship -that-. Today this is prename, with an aborted
> effort to make rename.ul possible instead. Given this previous
> effort, and some earlier discussion here, I think it is valid to say
> "/usr/bin/rename should be rename.ul" - but then it should be that,
> and prename should be prename.
> Otherwise I would like to keep the status quo: our choice for
> /usr/bin/rename is prename.

Sure. I was aiming at an incremental improvement here. This is not all
black and white. Giving those who need util-linux' rename a way to
obtain it is half the story. Making it the default is a separate step.
Whether that step is to be taken is an interesting question, but I think
that those who are in favour of it, should present a transition plan to
debian...@lists.debian.org.

> I however believe that Debian should make choices, for our users and
> in their interest. Shipping both (or maybe all rename-like tools)
> and having that user-configurable is IMO not a good technical choice
> and IMO also not in the interest of the larger community.

I think there is a difference between making that choice prominent and
making it possible. For instance, I am in favour of removing the debconf
choice for /bin/sh. Doing so makes the choice for /bin/sh a lot less
prominent. I am not in favour of removing support for using dpkg-divert
to change what /bin/sh points to. A consequence of that is that if you
encounter a dashism in some shell script, that's still a bug. In that
regard, yes, Debian should make choices for defaults. At the same time,
it should not unnecessarily alienate people who think otherwise. If the
cost for that choice is deemed to high (or not covered by those who are
in favour of it), dropping the choice may become necessary. Given that
practically nothing in the Debian archive uses /usr/bin/rename, I think
that deferring the choice where it points to to users (in a
non-prominent way) is a reasonable thing to do, precisely because
/usr/bin/rename is presently not consistent accross different Linux
distributions.

> It appears "we" cannot make up our mind about this very small
> utility. Why should we delegate this to our users then? If they are
> interested, they will sink even more time into it and maybe create a
> configuration that possibly causes problems in the future.

I believe that those who exercise their choice are a very small
minority. The majority will stick with whatever Debian chooses.

A non-prominent choice would be dpkg-divert. As soon as bsdextrautils
ships rename.ul, anyone can use dpkg-divert to change /usr/bin/rename.
The only other piece is requiring that no package uses /usr/bin/rename.
That task can be deferred to choice-proponents by having them send
patches.

Does that make more sense to you now?

Helmut

Dominic Hargreaves

unread,
Feb 7, 2022, 4:20:04 PM2/7/22
to
That's the conclusion I came to when I looked at this at the point of
packaging rename separately. There doesn't seem to be any benefit to
changing this command line interface in Debian at this stage even though
I don't think it should have been there in the first place.

Dominic

Christoph Berg

unread,
Feb 8, 2022, 5:20:03 AM2/8/22
to
Re: Chris Hofstaedtler
> Then all of this is a completely pointless exercise. Either we break
> them, or it is favorable to keeping the way things are:
>
> A very valid way of closing this discussion is saying "our
> (Perl) /usr/bin/rename is great, people should use that".

We seem to all agree that renaming the different rename
implementations is not helpful now, but there is still the original
question if ul's rename.ul could be put back to where it was before
the bullseye release. In the same package or a separate one.

Christoph

Helmut Grohne

unread,
Feb 8, 2022, 3:30:03 PM2/8/22
to
Hi Chris,

On Sun, Jan 23, 2022 at 10:04:34PM +0100, Chris Hofstaedtler wrote:
> I was hoping we could put util-linux' rename into the
> "bsdextrautils" binary package, which has utilities like write, col,
> etc; to avoid putting it into an Essentials: yes package, and to
> avoid a new binary package. However, picking bsdextrautils seems
> ... maybe not ideal if it should Conflict with rename.
>
> 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.

This paragraph can be vaguely interpreted as an intention to put the
util-linux rename implementation back into some binary package under
some path. Doing so would go a significant way towards what the
submitter of the ctte bug wants.

We've discussed a number of possible ways to put it back (various
packages, various paths, with or without update-alternatives, with or
without Conflicts). From what you said, I understand that:
* You disagree with putting it in some transitively essential package.
* You think that Debian should make a choice about the rename API and
stick to that.
* You take issue with "rename.ul" as a program name, because it is
inconsistent with other Linux distributions.
* You agree on shipping the util-linux rename executable (with
unspecified filename at this stage) in some Debian binary package in
principle.

Do you confirm these statements?

Given these, we think that much of the issue can be resolved
cooperatively. To get there we (as ctte) ask you to explain how you
prefer adding the util-linux rename executable as precisely as you see
it at this stage.

In your option,
* which binary package should contain the util-linux rename?
- bsdextrautils
- something else
* how should it be named?
- rename
- rename.ul
- something else
* where should it be installed?
- /usr/bin
- something else?
* should it be managed with update-alternatives?
* should there be a Conflicts or Breaks relation with the perl rename?

If you feel unable to answer any of these, please say so.

Thank you for taking the time to participate in this discussion.

Helmut

Philip Hands

unread,
Feb 9, 2022, 5:20:04 AM2/9/22
to
Helmut Grohne <hel...@subdivi.de> writes:

> * You take issue with "rename.ul" as a program name, because it is
> inconsistent with other Linux distributions.

Regarding this, perhaps we ought to ask util-linux's upstream if they'd
be willing to install /usr/bin/rename also as /usr/bin/rename.ul[1],
thus allowing people to write scripts that are portable across distros.

Cheers, Phil.

[1] If that is done with a symlink, I presume we'd have a very slight
preference for the actual binary to be called `rename.ul`, but it
doesn't really matter how it's done as long as people can rely on
rename.ul being present, regardless of distro.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/ http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY
signature.asc

Chris Hofstaedtler

unread,
Mar 28, 2022, 2:10:04 PM3/28/22
to
Hi Helmut,

* Helmut Grohne <hel...@subdivi.de> [220208 21:23]:
Yes.

I would like to say that my point of view would be "if we change
something, lets do the right thing going forward". If we need to
break with the past, lets do it now instead of delaying further.

> Given these, we think that much of the issue can be resolved
> cooperatively. To get there we (as ctte) ask you to explain how you
> prefer adding the util-linux rename executable as precisely as you see
> it at this stage.
>
> In your option,
> * which binary package should contain the util-linux rename?
> - bsdextrautils
> - something else

util-linux-extra. Unrelatedly, other non-essential binaries from
util-linux should also move into this package, but this is only
tangentially related.

> * how should it be named?
> - rename
> - rename.ul
> - something else
> * where should it be installed?
> - /usr/bin
> - something else?

/usr/bin/rename

> * should it be managed with update-alternatives?

No. My understanding is this would be a bug. Also, I subscribe to
the idea that (pseudo-)essential packages should not use the
update-alternatives mechanism. This last point might be easier
with util-linux-extra.

> * should there be a Conflicts or Breaks relation with the perl rename?

I think this will be necessary.

> If you feel unable to answer any of these, please say so.
>
> Thank you for taking the time to participate in this discussion.

I would like to ask a question: under which constitution point will
the CTTE act?

> Helmut

BR,
Chris
signature.asc

Helmut Grohne

unread,
Mar 28, 2022, 3:10:03 PM3/28/22
to
Hi Chris,

On Mon, Mar 28, 2022 at 07:58:11PM +0200, Chris Hofstaedtler wrote:
> I would like to ask a question: under which constitution point will
> the CTTE act?

Given your reply, I believe that no 6.1.1-4 decision is necessary. The
views of the submitter seem sufficiently covered in what you described.
I do not think there is a need to codify 6.1.5 advice either. It seems
that what happened was mediation. If a resolution is deemed necessary,
I'd propose "we decline to overrule the maintainer" with a rationale.
We'll likely figure that out on our next meeting in 8 days.

On the other hand, I'd like you to commit to including the util-linux
rename binary in time for the bookworm release (assuming NEW is
processed in a reasonable time). That likely implies that it needs to be
uploaded within 2022. Preferrably sooner. Can you confirm that?

Helmut

Christoph Berg

unread,
Mar 28, 2022, 4:40:03 PM3/28/22
to
Re: Chris Hofstaedtler
> > * which binary package should contain the util-linux rename?
> > - bsdextrautils
> > - something else
>
> util-linux-extra. Unrelatedly, other non-essential binaries from
> util-linux should also move into this package, but this is only
> tangentially related.

Hi,

I like that package name.

> > * where should it be installed?
> > - /usr/bin
> > - something else?
>
> /usr/bin/rename

> > * should there be a Conflicts or Breaks relation with the perl rename?
>
> I think this will be necessary.

The problem here is that if ul-extra contains things besides rename,
and it conflicts with the perl rename, people will rightfully complain
that they can't install /usr/bin/fincore-from-ul-extra and
/usr/bin/rename-from-perl at the same time.

Or would you solve that using alternatives, without the conflicts?

(Fwiw I believe the strict rule "alternatives only for compatible
interfaces" doesn't apply here - we are looking for a workaround, and
there is no rule saying that only hacks X, Y, Z must be used for
these. If alternatives are the best tool for the job, it should be
used.)

Christoph

Matthew Vernon

unread,
Mar 29, 2022, 4:10:03 AM3/29/22
to
Hi,

On 29/03/2022 00:55, Sean Whitton wrote:

> On Mon 28 Mar 2022 at 10:35PM +02, Christoph Berg wrote:
>
>> The problem here is that if ul-extra contains things besides rename,
>> and it conflicts with the perl rename, people will rightfully complain
>> that they can't install /usr/bin/fincore-from-ul-extra and
>> /usr/bin/rename-from-perl at the same time.
>
> Indeed, and doesn't it violate Policy 10.1, which says "Two different
> packages must not install programs with different functionality but with
> the same filenames" ? Perhaps it's an edge case.

Yeah, I don't think we serve our users by having two different packages
both of which want to install /usr/bin/rename.

I'm still not quite sure why the previous path is so objectionable - we
shipped /usr/bin/rename.ul for years, Debian (and derivative) users will
be expecting it there, having util-linux-extra (WLOG) install it there
seems like the right answer (and the one least surprising to our users)...

Regards,

Matthew

Philip Hands

unread,
Mar 29, 2022, 7:20:04 AM3/29/22
to
Christoph Berg <my...@debian.org> writes:

> Re: Chris Hofstaedtler
>> > * which binary package should contain the util-linux rename?
>> > - bsdextrautils
>> > - something else
>>
>> util-linux-extra. Unrelatedly, other non-essential binaries from
>> util-linux should also move into this package, but this is only
>> tangentially related.
>
> Hi,
>
> I like that package name.
>
>> > * where should it be installed?
>> > - /usr/bin
>> > - something else?
>>
>> /usr/bin/rename
>
>> > * should there be a Conflicts or Breaks relation with the perl rename?
>>
>> I think this will be necessary.
>
> The problem here is that if ul-extra contains things besides rename,
> and it conflicts with the perl rename, people will rightfully complain
> that they can't install /usr/bin/fincore-from-ul-extra and
> /usr/bin/rename-from-perl at the same time.
>
> Or would you solve that using alternatives, without the conflicts?

Is it possible to have alternatives default to installing neither option
by default?

I suspect not, but something like that might allow local admins to
install either as /usr/bin/rename while not encouraging the use of that
path in packaging scripts (which should use either rename.ul or
file-rename to get the version they really want).

I suppose the same result could be constructed with a shared
low-priority debconf question about which to use, defaulting to neither.

An approach which strikes me as inelegant, but ought to work, would be
for something essential to provide the default alternative as a script
that spits out a warning that you should be using whichever of the
specific names you really meant, or that you could define 'rename' as an
alias in your profile, or even that you might use update-alternetives to
install one of them as 'rename' system-wide.

Cheers, Phil.
signature.asc

Christoph Berg

unread,
Apr 6, 2022, 4:00:03 PM4/6/22
to
Re: Matthew Vernon
Hi Chris,

the TC was discussing this issue at the meeting on Tuesday.

We acknowledge that there are several possible ways to install it and
steer around the fact that there's also the "perl" rename. Probably
all of these have their warts - the above summarizes the current views
of the TC members: having util-linux-extra conflict with the perl
rename while it contains other binaries is undesirable, and a more
fine-grained solution would be preferred. Or just provide it under the
old name.

Could you outline the plan you have with bringing rename(.ul) back?
Would it be possible to give us feedback until the end of this month,
so we can wrap it up before the next TC meeting?

Thanks,
Christoph
Debian Technical Committee

Chris Hofstaedtler

unread,
Apr 7, 2022, 7:10:04 AM4/7/22
to
Hello Christoph,

* Christoph Berg <my...@debian.org> [220406 21:55]:
> the TC was discussing this issue at the meeting on Tuesday.
>
> We acknowledge that there are several possible ways to install it and
> steer around the fact that there's also the "perl" rename. Probably
> all of these have their warts - the above summarizes the current views
> of the TC members: having util-linux-extra conflict with the perl
> rename while it contains other binaries is undesirable, and a more
> fine-grained solution would be preferred. Or just provide it under the
> old name.

> Could you outline the plan you have with bringing rename(.ul) back?
> Would it be possible to give us feedback until the end of this month,
> so we can wrap it up before the next TC meeting?

I see two clear options:

A) Keep the status quo ("rename is not part of Debians util-linux").
Very clear, very simple, no work.

B) Finish the very old migration. Have util-linux(-extra) ship
/usr/bin/rename; perl rename can be prename/file-rename as today,
but would need to drop the update-alternatives symlink; versioned
Conflicts/Provides/Replaces would probably be needed. I would also
suggest having no binary package ship /usr/bin/rename for one
release.

This is also a very clear option:

- All code can in the future assume /usr/bin/rename to have the same
interface across distributions. Even Debian code.
- Does not need update-alternatives in an Essential package (= no
postinst fragment).
Less of an issue if /usr/bin/rename will be in util-linux-extra.
- One thing less in src:util-linux that needs dh-exec (which is
orphaned and I want to get rid of).
- Debian can ship both variants under "nice enough" names.

I understand this is an unpopular move with current file-rename/prename
users. At the same time this option resolves to an outcome that various
people before me thought was technically desirable.
It needs changes to src:rename, but Dominic is in the loop on this
thread and I did not hear technical issues so far against those
changes. Maybe it would be a weird thing for the binary package
"rename" to not install a program named "rename".

Note rgd util-linux-extra: I am trying to reduce the installed
size of util-linux, by splitting "not so essential" utilities
out of it (and maybe merging a few of the whateverextra packages
into a new util-linux-extra). But for at least one release,
util-linux-extra would need to be transitively pseudo-Essential
(via util-linux).

A variant of this option could be to take over the "rename" binary
package name by src:util-linux, but that would also be a
two-release process, I think. I.e. in bookworm src:rename could
introduce a file-rename package, depend on that from the rename
binary package, then drop it in bookworm+1, and util-linux could
take that binary package name. Or in bookworm+2.

Personally I am leaning towards option A) - mostly because we
are/were already spending a lot more time on mails than what I think
the work of option B) would entail. Also I believe the CTTE does not
want to do any of this fine grainted technical detail design work.

Chris

Christoph Berg

unread,
Apr 7, 2022, 9:20:03 AM4/7/22
to
Re: Chris Hofstaedtler
> I see two clear options:

Hi Chris,

thanks for the prompt feedback!

> A) Keep the status quo ("rename is not part of Debians util-linux").
> Very clear, very simple, no work.

But that's not what users want, there have been several requests to
have rename reintroduced.

> B) Finish the very old migration. Have util-linux(-extra) ship
> /usr/bin/rename; perl rename can be prename/file-rename as today,
> but would need to drop the update-alternatives symlink; versioned
> Conflicts/Provides/Replaces would probably be needed. I would also
> suggest having no binary package ship /usr/bin/rename for one
> release.

What name would you use in util-linux-extra for the time of the one
release where no package ships /usr/bin/rename? /usr/bin/rename.ul
seems most sensible to me here, which would also match the status
before starting a migration.

> Personally I am leaning towards option A) - mostly because we
> are/were already spending a lot more time on mails than what I think
> the work of option B) would entail. Also I believe the CTTE does not
> want to do any of this fine grainted technical detail design work.

We don't want to dictate *how* this should be resolved, but we are
interested in *having* it resolved, and A) isn't that.

To me, the plausible way forward here seems to be this:

* Reintroduce it as /usr/bin/rename.ul in util-linux-extra
* Have u-l-e be pseudo-essential for one release
* At this point the TC issue is resolved
* Potentially work with the perl-rename maintainers to transition to a
different layout of the two utilities. That's then indeed outside
the scope of the TC.

Christoph

Chris Hofstaedtler

unread,
Apr 9, 2022, 10:10:03 AM4/9/22
to
Hello Christoph,

* Christoph Berg <my...@debian.org> [220407 15:11]:
> Re: Chris Hofstaedtler
> > B) Finish the very old migration. Have util-linux(-extra) ship
> > /usr/bin/rename; perl rename can be prename/file-rename as today,
> > but would need to drop the update-alternatives symlink; versioned
> > Conflicts/Provides/Replaces would probably be needed. I would also
> > suggest having no binary package ship /usr/bin/rename for one
> > release.
>
> What name would you use in util-linux-extra for the time of the one
> release where no package ships /usr/bin/rename? /usr/bin/rename.ul
> seems most sensible to me here, which would also match the status
> before starting a migration.

I was not planning on doing that: stable already does not have
/usr/bin/rename.ul.

> > Personally I am leaning towards option A) - mostly because we
> > are/were already spending a lot more time on mails than what I think
> > the work of option B) would entail. Also I believe the CTTE does not
> > want to do any of this fine grainted technical detail design work.
>
> We don't want to dictate *how* this should be resolved, but we are
> interested in *having* it resolved, and A) isn't that.
>
> To me, the plausible way forward here seems to be this:
>
> * Reintroduce it as /usr/bin/rename.ul in util-linux-extra
> * Have u-l-e be pseudo-essential for one release
> * At this point the TC issue is resolved
> * Potentially work with the perl-rename maintainers to transition to a
> different layout of the two utilities. That's then indeed outside
> the scope of the TC.

Given rename.ul is not in stable (bullseye), I do not think we
should do this. From a compatibility point of view, we do not win
anything. At this point, we are more talking about shipping a new
program in a new place, than continuing to ship an existing program.

If we were talking about all of this before the stable release, I
would be a lot more open about other options. But by now almost two
years have passed since the change, and bullseye is out for ~ 9
months.

I know we all want this TC issue to be resolved. But I do not want
to end up shipping rename.ul indefinitely.

Chris

Matthew Vernon

unread,
Apr 9, 2022, 10:20:04 AM4/9/22
to
Hi,

On 09/04/2022 14:59, Chris Hofstaedtler wrote:

> I was not planning on doing that: stable already does not have
> /usr/bin/rename.ul.

People were asking for it to be restored before the stable release,
though, I think? #966468 was opened against version 2.36-1 back in July
2020.

> Given rename.ul is not in stable (bullseye), I do not think we
> should do this. From a compatibility point of view, we do not win
> anything. At this point, we are more talking about shipping a new
> program in a new place, than continuing to ship an existing program.

I disagree; we have historically shipped rename.ul, we didn't in stable
(against the wishes of at least some of our users), but I don't think
that means that restoring it again would be "shipping a new program in a
new place" in a meaningful sense.

> If we were talking about all of this before the stable release, I
> would be a lot more open about other options. But by now almost two
> years have passed since the change, and bullseye is out for ~ 9
> months.

Issues are slow to get to the TC, and the TC is often slow to resolve
them; I think "escalate to the TC rapidly or the status quo ante will
prevail" is not a line I want to encourage.

> I know we all want this TC issue to be resolved. But I do not want
> to end up shipping rename.ul indefinitely.

I'm still not sure what harm occurs from doing so?

Regards,

Matthew

Chris Hofstaedtler

unread,
Apr 9, 2022, 12:20:04 PM4/9/22
to
* Matthew Vernon <mat...@debian.org> [220409 16:12]:
> On 09/04/2022 14:59, Chris Hofstaedtler wrote:
[..]
> > I know we all want this TC issue to be resolved. But I do not want
> > to end up shipping rename.ul indefinitely.
>
> I'm still not sure what harm occurs from doing so?

I gave some technical reasons why I do not want to, upthread.
I would also request that my decision is respected - regardless if I
give technical or social reasons for it, or not. Maintainers have
ideas and/or plans how the packages they maintain should look like,
and which functions they should provide. Unless the TC wants to rule
on a maintainer override, this should be enough.

To add a social reason: if rename from src:util-linux is again
shipped under a name other than "rename", I am very sure people will
(re-)open bugs about "missing" update-alternatives setup to switch
incompatible "rename" interfaces. And probably complain again on
mailing lists and/or in LWN comments if such a bug gets closed.

I'll spare you my ideas on what this does to the motivation of
individual maintainers.

Anyway.
I do not see what bringing back "rename.ul" at this point helps
anyone. The compatibility ship has sailed. Companies and
institutions relying on "rename.ul" in future distribution versions
certainly have the resources of building their own
"just-rename.ul-from-util-linux.deb" which can work across Debian
(and derivatives) versions.
I'm up for making changes towards a simpler future.

Chris

Helmut Grohne

unread,
Apr 9, 2022, 1:10:04 PM4/9/22
to
Hi Dom and Chris,

Chris proposes to transition /usr/bin/rename from the perl API to the
util-linux API.

On Thu, Apr 07, 2022 at 01:04:54PM +0200, Chris Hofstaedtler wrote:
> I see two clear options:

[...]

> B) Finish the very old migration. Have util-linux(-extra) ship
> /usr/bin/rename; perl rename can be prename/file-rename as today,
> but would need to drop the update-alternatives symlink; versioned
> Conflicts/Provides/Replaces would probably be needed. I would also
> suggest having no binary package ship /usr/bin/rename for one
> release.
>
> This is also a very clear option:
>
> - All code can in the future assume /usr/bin/rename to have the same
> interface across distributions. Even Debian code.
> - Does not need update-alternatives in an Essential package (= no
> postinst fragment).
> Less of an issue if /usr/bin/rename will be in util-linux-extra.
> - One thing less in src:util-linux that needs dh-exec (which is
> orphaned and I want to get rid of).
> - Debian can ship both variants under "nice enough" names.

Dom (or whoever maintains perl's rename now), would you agree to release
the /usr/bin/rename name to use it for util-linux' implementation
retaining prename for the perl implementation?

A little background (for newly added participants):

We have two conflicting APIs for /usr/bin/rename. The perl API has
historical precedent in Debian. The util-linux API tends to be used more
widely accross other Linux distributions (in particular Fedora). We
cannot have /usr/bin/rename both be compatible with old versions of
Debian and current versions of Fedora. That leaves us in the difficult
spot where we get to decide which compatibility to keep. Chris
essentially wants the util-linux implementation to either not be shipped
at all or filling the /usr/bin/rename spot. So now, we're asking the
perl side for their view on this.

If /usr/bin/rename is to be transitioned from perl to util-linux, I
think we should have a proper announcement on debian...@l.d.o or
better d-d-a before doing it, but getting the input from the perl side
seems to be a prerequisite.

Helmut

gregor herrmann

unread,
Apr 9, 2022, 9:30:04 PM4/9/22
to
On Sat, 09 Apr 2022 19:00:37 +0200, Helmut Grohne wrote:

> Chris proposes to transition /usr/bin/rename from the perl API to the
> util-linux API.
[..]
> Dom (or whoever maintains perl's rename now), would you agree to release
> the /usr/bin/rename name to use it for util-linux' implementation
> retaining prename for the perl implementation?

(The "whoever" was and is the Debian Perl Group :))


I'd like to quote Chris and Dom from #114 in this bug:

On Tue, Jan 25, 2022 at 09:16:25AM +0100, Chris Hofstaedtler wrote:
> A very valid way of closing this discussion is saying "our
> (Perl) /usr/bin/rename is great, people should use that".

That's the conclusion I came to when I looked at this at the point of
packaging rename separately. There doesn't seem to be any benefit to
changing this command line interface in Debian at this stage even though
I don't think it should have been there in the first place.

Dominic

I think this conclusion still holds.


Some additional thoughts:
* Shipping u-l's rename as /usr/bin/rename.ul might be nice for users
who want to use it and are already used to this name.
* Switching /usr/bin/rename from perl's rename to u-l's rename will
break interactive and scripted user experience.
* A Conflicts of a new util-linux-$something against file-rename will
be painful for users.
* Personally I very much prefer compatibility with Debian's history
over compatibility with Fedora.
* Side note: "releasing the /usr/bin/rename name" is an interesting
framing.


Cheers,
gregor

--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`-
signature.asc

Dominic Hargreaves

unread,
Apr 10, 2022, 10:10:04 AM4/10/22
to
+1 to all of this.

Furthermore I'm troubled that this discussion rolled on for two months
having dropped the perl folk, in a circular fashion. That doesn't seem
to be in the spirit of cooperation alluded to in

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003653#122

Helmut Grohne

unread,
Apr 10, 2022, 1:40:04 PM4/10/22
to
Hi Dom and gregor,

On Sun, Apr 10, 2022 at 03:06:56PM +0100, Dominic Hargreaves wrote:
> +1 to all of this.

Thank you for your replies. They're not unexpected, but we (or at least
I) weren't entirely sure.

> Furthermore I'm troubled that this discussion rolled on for two months
> having dropped the perl folk, in a circular fashion. That doesn't seem
> to be in the spirit of cooperation alluded to in
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003653#122

At that time, we (ctte) didn't really consider changing the
/usr/bin/rename API to be a viable option, but apparently Chris did and
that only became fully clear much later. Thus the question popped up
now.

In any case, we now have three relevant opinions that form a
contradiction when combined:

* Submitter: The util-linux rename implementation should be included in
Debian
* Chris: The util-linux rename should be either /usr/bin/rename or
absent.
* Dom/gregor: /usr/bin/rename should be perl rename.

In all of this discussion, I think we didn't have such a clear
understanding of the disagreement. It always looked solvable in a
consensual way to me. That has somewhat changed now.

The next step is checking back with Chris on whether his position could
be adjusted. I would still prefer resolving this without using special
ctte powers.

Helmut

Helmut Grohne

unread,
Apr 10, 2022, 4:20:03 PM4/10/22
to
Hi Chris,

On Thu, Apr 07, 2022 at 01:04:54PM +0200, Chris Hofstaedtler wrote:
> I see two clear options:
>
> A) Keep the status quo ("rename is not part of Debians util-linux").
> Very clear, very simple, no work.

This option is obviously incompatible with the request to restore
util-linux' rename. I think we have pretty wide consensus that we do not
want this option.

> B) Finish the very old migration. Have util-linux(-extra) ship
> /usr/bin/rename; perl rename can be prename/file-rename as today,
> but would need to drop the update-alternatives symlink; versioned
> Conflicts/Provides/Replaces would probably be needed. I would also
> suggest having no binary package ship /usr/bin/rename for one
> release.

I've checked back with the perl people and with other ctte members.
Consensus is that we do not want to "finish" this transition. We expect
that /usr/bin/rename only has the perl API on Debian systems.

Do you see any other options or compromises that you'd be comfortable
with?

At this point, it is very clear that we will be unable to reconcile the
position of the submitter (provide util-linux' rename somewhere), the
position of the perl rename maintainers (retain perl API for
/usr/bin/rename) and your stated position (option A or option B). One of
these will have to move and we think it needs to be yours.

Helmut

James Cloos

unread,
Apr 11, 2022, 9:00:03 AM4/11/22
to
from a user pov, i'd hate not to have the perl renae at /usr/bin/rename.

i've been using it since the early '90s and its re support is essetial.

i very uch doubt i'm alone in that.

-JimC
--
James Cloos <cl...@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6

Dominic Hargreaves

unread,
Apr 11, 2022, 5:30:03 PM4/11/22
to
Thanks for the clarification.

By the way, it's possible that this discussion has taken place without
reference to the original bug where these issues were discussed at length:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735134

I should have provided this link back in February when we were first
asked about it; mea culpa. I hope this is helpful.

Dominic

Chris Hofstaedtler

unread,
Apr 12, 2022, 11:20:04 AM4/12/22
to
* Helmut Grohne <hel...@subdivi.de> [220410 22:13]:
> I've checked back with the perl people and with other ctte members.
> Consensus is that we do not want to "finish" this transition. We expect
> that /usr/bin/rename only has the perl API on Debian systems.
>
> Do you see any other options or compromises that you'd be comfortable
> with?

No.

Chris

Matthew Vernon

unread,
Apr 14, 2022, 12:00:09 PM4/14/22
to
Hi,

Thanks to everyone for your contributions to this discussion. I think
we're at the point where voting is appropriate.

I propose a ballot as follows - if no-one suggests further options in
the mean time, I will call for a vote on this ballot on Tuesday, after
the weekend of public holidays.

===Rationale

There are two "rename" programs - the perl rename, and the util-linux
rename. Debian and its derivatives have shipped the perl rename as
/usr/bin/rename, whilst other distributions (e.g. Fedora) have shipped
the util-linux rename thus. The two implementations are incompatible.
Users might reasonably desire both implementations to be available on
the same system.

Backwards-compatibility (and the lack of a compelling argument that
util-linux's rename is significantly superior to the perl rename) means
that /usr/bin/rename in Debian should remain the perl rename.

Prior to bullseye, util-linux's rename was shipped as
/usr/bin/rename.ul; Debian's users who wish to use util-linux's rename
will expect it to be in this location.

===End Rationale

===Begin Resolution

The Technical Committee resolves that util-linux's rename should be
shipped in a binary package build from src:util-linux. If this package
Conflicts with the rename package, then it should not contain any other
binaries.

The Technical Committee overrides the util-linux maintainer, and
requires that this binary should be shipped as /usr/bin/rename.ul

===End Resolution

A: Approve resolution, including override of util-linux maintainer
B: Approve only first paragraph of resolution
N: None of the above

Regards,

Matthew
ps; my first TC resolution, please be gentle if I have the procedure wrong!

Gunnar Wolf

unread,
Apr 15, 2022, 2:40:03 AM4/15/22
to
Thanks for drafting this, Matthew!

I have a small suggestion here:

Matthew Vernon dijo [Thu, Apr 14, 2022 at 04:47:17PM +0100]:
> Backwards-compatibility (and the lack of a compelling argument that
> util-linux's rename is significantly superior to the perl rename) means that
> /usr/bin/rename in Debian should remain the perl rename.

I'd prefer to read "that neither 'rename' implementation is superior
to the other", maybe even explaining that "they were designed out of
different needs and meet different criteria".

> The Technical Committee resolves that util-linux's rename should be shipped
> in a binary package build from src:util-linux. If this package Conflicts
^built

> Matthew
> ps; my first TC resolution, please be gentle if I have the procedure wrong!

Thanks again!

Matthew Vernon

unread,
Apr 15, 2022, 3:30:04 PM4/15/22
to
On 15/04/2022 07:36, Gunnar Wolf wrote:

> Matthew Vernon dijo [Thu, Apr 14, 2022 at 04:47:17PM +0100]:
>> Backwards-compatibility (and the lack of a compelling argument that
>> util-linux's rename is significantly superior to the perl rename) means that
>> /usr/bin/rename in Debian should remain the perl rename.
>
> I'd prefer to read "that neither 'rename' implementation is superior
> to the other", maybe even explaining that "they were designed out of
> different needs and meet different criteria".

I intended to cover that in the first paragraph; my point here was that
there would need to be some compelling reason to change our
/usr/bin/rename implementation now (such as the util-linux one being
much better). I'll try and draft it better.

Regards,

Matthew

Matthew Vernon

unread,
Apr 15, 2022, 4:00:05 PM4/15/22
to
Hi,

Thanks for the feedback on my previous draft; here's a revised ballot.

I propose a ballot as follows - if no-one suggests further options in
the mean time, I will call for a vote on this ballot on Tuesday, after
the weekend of public holidays.

From a procedural point of view, I am formally withdrawing both ballot
options I proposed in <9012b2bf-dd1f-afc4...@debian.org>
(thus voiding that process per constitution 6.3.1.3), and starting afresh.

===Rationale

There are two "rename" programs - the perl rename, and the util-linux
rename. Debian and its derivatives have shipped the perl rename as
/usr/bin/rename, whilst other distributions (e.g. Fedora) have shipped
the util-linux rename thus. The two implementations are incompatible.
Users might reasonably desire both implementations to be available on
the same system; they are designed to meet different needs.

Backwards-compatibility (and the lack of a compelling argument that
rename from util-linux should replace perl rename) means that
/usr/bin/rename in Debian should remain the perl rename.

Prior to bullseye, util-linux's rename was shipped as
/usr/bin/rename.ul; Debian's users who wish to use util-linux's rename
will expect it to be in this location.

===End Rationale

===Begin Resolution

The Technical Committee overrides the util-linux maintainer, and
requires that util-linux's rename should be shipped in a binary package
built from src:util-linux. If this package Conflicts with the rename
package, then it should not contain any other binaries.

The Technical Committee further requires that this binary should be
shipped as /usr/bin/rename.ul

===End Resolution

A: Override util-linux maintainer, approve entire resoltuion
B: Override util-linux maintainer, approve only first paragraph of

Russ Allbery

unread,
Apr 15, 2022, 4:30:03 PM4/15/22
to
Sean Whitton <spwh...@spwhitton.name> writes:

> In this case I believe you need to formally withdraw options A&B and
> then propose another ballot.

Minor procedural point: the person proposing the options can also freely
modify them, so you didn't technically have to withdraw them and could
instead just alter the options to whatever new text you want. 6.3.2:

Any member of the Technical Committee may propose additional ballot
options or modify or withdraw a ballot option they proposed.

(The underlying assumption is that the TC are sophisticated voters who can
closely track the status of the ballot, so we can err on the side of
convenience to let proposers rewrite the options to whatever they want.
If that makes previously acceptable options unacceptable, other TC members
can always propose new options or reinstate versions of the previous
options.)

--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>

Helmut Grohne

unread,
Apr 16, 2022, 4:30:03 AM4/16/22
to
Hi Matthew,

On Fri, Apr 15, 2022 at 08:54:16PM +0100, Matthew Vernon wrote:
> Thanks for the feedback on my previous draft; here's a revised ballot.

Thank you for moving this forward.

> ===Rationale
>
> There are two "rename" programs - the perl rename, and the util-linux
> rename. Debian and its derivatives have shipped the perl rename as
> /usr/bin/rename, whilst other distributions (e.g. Fedora) have shipped the
> util-linux rename thus. The two implementations are incompatible. Users
> might reasonably desire both implementations to be available on the same
> system; they are designed to meet different needs.
>
> Backwards-compatibility (and the lack of a compelling argument that rename
> from util-linux should replace perl rename) means that /usr/bin/rename in
> Debian should remain the perl rename.
>
> Prior to bullseye, util-linux's rename was shipped as /usr/bin/rename.ul;
> Debian's users who wish to use util-linux's rename will expect it to be in
> this location.
>
> ===End Rationale

Thank you and others for this. It looks good to me.

> ===Begin Resolution
>
> The Technical Committee overrides the util-linux maintainer, and requires
> that util-linux's rename should be shipped in a binary package built from
> src:util-linux. If this package Conflicts with the rename package, then it
> should not contain any other binaries.
>
> The Technical Committee further requires that this binary should be shipped
> as /usr/bin/rename.ul
>
> ===End Resolution
>
> A: Override util-linux maintainer, approve entire resoltuion
> B: Override util-linux maintainer, approve only first paragraph of
> resolution
> N: None of the above

I would like to propose two modifications to the ballot.

1. While the former "should" is guarded by "requires", I think the
latter can be read as a recommendation. I therefore propose replacing
it with "must" to make the override more obvious.

2. While option B reads fine to me, option A is a little confusing to
me due to the combination of the naming requirement with the
mentioning of the conflict. Given the rename.ul name, there seems to
be no reason to cause a conflict at all and we can simply require
that. As such I think the options should be fully separated.

===Begin Resolution A'
The Technical Committee overrides the util-linux maintainer, and
requires that util-linux's rename should be shipped as
/usr/bin/rename.ul in a binary package built from src:util-linux. The
package containing rename.ul must not conflict with the rename package
nor divert /usr/bin/rename.
===End Resolution A'

===Begin Resolution B'
The Technical Committee overrides the util-linux maintainer, and requires
that util-linux's rename should be shipped in a binary package built from
src:util-linux. If this package Conflicts with the rename package, then it
must not contain any other binaries.
===End Resolution B'

Do these modifications go with your intents and do you want to accept A'
and B' as a A and B respectively?

In the past discussions on this matter, I was a major force in delaying
a ruling in an attempt to resolve this consensually instead of using
overriding power and recommended overriding as little as necessary.
However, I think that any outcome where we have u-l's rename package
conflict with rename is bad for users, because it makes installation
sets impossible where a user wants u-l's rename together with some
package that happens to depend on rename. This is unlike /usr/bin/python
(which also has mutually incompatible interfaces), because we require
that no package depends on python-is-python3 nor python-is-python2. We
have no such requirement for rename at this time. For that reason, I now
think that any solution involving a conflict with rename is going to
cause problems sooner or later unless we also require /usr/bin/rename to
be shipped by rename-is-prename or rename-is-rename.ul only.

The previous paragraph is not meant to influence available vote options.
It is only given as a guide on the implications of the vote. Possibly,
it would make sense to extend the rationale of option A with a reason
for denying the conflict though.

Helmut

Matthew Vernon

unread,
Apr 16, 2022, 10:10:04 AM4/16/22
to
Hi,

Thanks for this.

> 1. While the former "should" is guarded by "requires", I think the
> latter can be read as a recommendation. I therefore propose replacing
> it with "must" to make the override more obvious.
>
> 2. While option B reads fine to me, option A is a little confusing to
> me due to the combination of the naming requirement with the
> mentioning of the conflict. Given the rename.ul name, there seems to
> be no reason to cause a conflict at all and we can simply require
> that. As such I think the options should be fully separated.

I think I would generally like TC resolutions to be "natural English to
be interpreted pragmatically, particularly in light of the rationale"
rather than bullet-proof legalese. Now is not the time to die on this
particular hill, though :-)

> ===Begin Resolution A'
> The Technical Committee overrides the util-linux maintainer, and
> requires that util-linux's rename should be shipped as
> /usr/bin/rename.ul in a binary package built from src:util-linux. The
> package containing rename.ul must not conflict with the rename package
> nor divert /usr/bin/rename.
> ===End Resolution A'
>
> ===Begin Resolution B'
> The Technical Committee overrides the util-linux maintainer, and requires
> that util-linux's rename should be shipped in a binary package built from
> src:util-linux. If this package Conflicts with the rename package, then it
> must not contain any other binaries.
> ===End Resolution B'

I hereby modify my options A and B to replace them with the contents of
A' and B' thus.

[I'll do the necessary C&P when calling for a vote on the ballot]

Thanks,

Matthew

Matthew Vernon

unread,
Apr 20, 2022, 10:40:04 AM4/20/22
to
Hi,

I hereby call for a vote on the following ballot. Unless a TC member
objects to calling for a vote, voting lasts for a week, or until the
result is no longer in doubt.

===Rationale

There are two "rename" programs - the perl rename, and the util-linux
rename. Debian and its derivatives have shipped the perl rename as
/usr/bin/rename, whilst other distributions (e.g. Fedora) have shipped
the util-linux rename thus. The two implementations are incompatible.
Users might reasonably desire both implementations to be available on
the same system; they are designed to meet different needs.

Backwards-compatibility (and the lack of a compelling argument that
rename from util-linux should replace perl rename) means that
/usr/bin/rename in Debian should remain the perl rename.

Prior to bullseye, util-linux's rename was shipped as
/usr/bin/rename.ul; Debian's users who wish to use util-linux's rename
will expect it to be in this location.

===End Rationale

===Begin Resolution A
The Technical Committee overrides the util-linux maintainer, and
requires that util-linux's rename should be shipped as
/usr/bin/rename.ul in a binary package built from src:util-linux. The
package containing rename.ul must not conflict with the rename package
nor divert /usr/bin/rename.
===End Resolution A

===Begin Resolution B
The Technical Committee overrides the util-linux maintainer, and
requires that util-linux's rename should be shipped in a binary package
built from src:util-linux. If this package Conflicts with the rename
package, then it must not contain any other binaries.
===End Resolution B

===Begin Resolution N
None of the above
===End Resolution N

I vote A > B > N

Regards,

Matthew
OpenPGP_signature

Gunnar Wolf

unread,
Apr 20, 2022, 11:40:03 AM4/20/22
to
Thank you very much for drafting the ballot, Matthew!

Matthew Vernon dijo [Wed, Apr 20, 2022 at 03:31:13PM +0100]:
> ===Begin Resolution A
> The Technical Committee overrides the util-linux maintainer, and requires
> that util-linux's rename should be shipped as /usr/bin/rename.ul in a binary
> package built from src:util-linux. The package containing rename.ul must not
> conflict with the rename package nor divert /usr/bin/rename.
> ===End Resolution A
>
> ===Begin Resolution B
> The Technical Committee overrides the util-linux maintainer, and requires
> that util-linux's rename should be shipped in a binary package built from
> src:util-linux. If this package Conflicts with the rename package, then it
> must not contain any other binaries.
> ===End Resolution B
>
> ===Begin Resolution N
> None of the above
> ===End Resolution N

I vote A > B > N

Thanks!
signature.asc

Helmut Grohne

unread,
Apr 20, 2022, 2:40:04 PM4/20/22
to
On Wed, Apr 20, 2022 at 03:31:13PM +0100, Matthew Vernon wrote:
> ===Begin Resolution A
> The Technical Committee overrides the util-linux maintainer, and requires
> that util-linux's rename should be shipped as /usr/bin/rename.ul in a binary
> package built from src:util-linux. The package containing rename.ul must not
> conflict with the rename package nor divert /usr/bin/rename.
> ===End Resolution A
>
> ===Begin Resolution B
> The Technical Committee overrides the util-linux maintainer, and requires
> that util-linux's rename should be shipped in a binary package built from
> src:util-linux. If this package Conflicts with the rename package, then it
> must not contain any other binaries.
> ===End Resolution B
>
> ===Begin Resolution N
> None of the above
> ===End Resolution N

I vote A > B > N.

Helmut
signature.asc

Christoph Berg

unread,
Apr 21, 2022, 4:40:04 PM4/21/22
to
> ===Begin Resolution A
> The Technical Committee overrides the util-linux maintainer, and requires
> that util-linux's rename should be shipped as /usr/bin/rename.ul in a binary
> package built from src:util-linux. The package containing rename.ul must not
> conflict with the rename package nor divert /usr/bin/rename.
> ===End Resolution A
>
> ===Begin Resolution B
> The Technical Committee overrides the util-linux maintainer, and requires
> that util-linux's rename should be shipped in a binary package built from
> src:util-linux. If this package Conflicts with the rename package, then it
> must not contain any other binaries.
> ===End Resolution B
>
> ===Begin Resolution N
> None of the above
> ===End Resolution N

I vote A > B > N.

Christoph
signature.asc

Niko Tyni

unread,
Apr 26, 2022, 1:30:04 AM4/26/22
to
On Wed, Apr 20, 2022 at 03:31:13PM +0100, Matthew Vernon wrote:

> ===Begin Resolution A
> The Technical Committee overrides the util-linux maintainer, and requires
> that util-linux's rename should be shipped as /usr/bin/rename.ul in a binary
> package built from src:util-linux. The package containing rename.ul must not
> conflict with the rename package nor divert /usr/bin/rename.
> ===End Resolution A
>
> ===Begin Resolution B
> The Technical Committee overrides the util-linux maintainer, and requires
> that util-linux's rename should be shipped in a binary package built from
> src:util-linux. If this package Conflicts with the rename package, then it
> must not contain any other binaries.
> ===End Resolution B
>
> ===Begin Resolution N
> None of the above
> ===End Resolution N

Sorry for the delay.

I vote: A > N > B

--
Niko Tyni nt...@debian.org
signature.asc

Simon McVittie

unread,
Apr 26, 2022, 9:00:04 AM4/26/22
to
On Wed, 20 Apr 2022 at 15:31:13 +0100, Matthew Vernon wrote:
> ===Begin Resolution A
> The Technical Committee overrides the util-linux maintainer, and requires
> that util-linux's rename should be shipped as /usr/bin/rename.ul in a binary
> package built from src:util-linux. The package containing rename.ul must not
> conflict with the rename package nor divert /usr/bin/rename.
> ===End Resolution A
>
> ===Begin Resolution B
> The Technical Committee overrides the util-linux maintainer, and requires
> that util-linux's rename should be shipped in a binary package built from
> src:util-linux. If this package Conflicts with the rename package, then it
> must not contain any other binaries.
> ===End Resolution B
>
> ===Begin Resolution N
> None of the above
> ===End Resolution N

I vote A > B > N.

smcv
signature.asc

Matthew Vernon

unread,
Apr 29, 2022, 2:50:03 PM4/29/22
to
On 20/04/2022 15:31, Matthew Vernon wrote:

> I hereby call for a vote on the following ballot. Unless a TC member
> objects to calling for a vote, voting lasts for a week, or until the
> result is no longer in doubt.

The voting period is over.

> ===Rationale
>
> There are two "rename" programs - the perl rename, and the util-linux
> rename. Debian and its derivatives have shipped the perl rename as
> /usr/bin/rename, whilst other distributions (e.g. Fedora) have shipped
> the util-linux rename thus. The two implementations are incompatible.
> Users might reasonably desire both implementations to be available on
> the same system; they are designed to meet different needs.
>
> Backwards-compatibility (and the lack of a compelling argument that
> rename from util-linux should replace perl rename) means that
> /usr/bin/rename in Debian should remain the perl rename.
>
> Prior to bullseye, util-linux's rename was shipped as
> /usr/bin/rename.ul; Debian's users who wish to use util-linux's rename
> will expect it to be in this location.
>
> ===End Rationale
>
> ===Begin Resolution A
> The Technical Committee overrides the util-linux maintainer, and
> requires that util-linux's rename should be shipped as
> /usr/bin/rename.ul in a binary package built from src:util-linux. The
> package containing rename.ul must not conflict with the rename package
> nor divert /usr/bin/rename.
> ===End Resolution A

Resolution A wins, with 7 first preference votes (and no other votes).

Regards,

Matthew
0 new messages