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

[Matthew Vernon]

Dear Chris,

Thanks for your contributions to the discussion of Bug 1003653. Here's a 
copy of the Technical Committee's decision on the question; if you've 
got any questions about any of this, please let us know.


Thanks,

Matthew


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

Resent-Date: Fri, 29 Apr 2022 18:45:01 +
Resent-From: Matthew Vernon 
Resent-To: debian-bugs-d...@lists.debian.org
Resent-CC: Technical Committee 
Date: Fri, 29 Apr 2022 19:41:46 +0100
From: Matthew Vernon 
Reply-To: Matthew Vernon , 1003...@bugs.debian.org
To: 1003...@bugs.debian.org

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

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

[Matthew Vernon]

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

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

[Simon McVittie]

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
Description: PGP signature

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

[Niko Tyni]

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
Description: PGP signature

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

[Christoph Berg]

> ===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
Description: PGP signature

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

[Sean Whitton]

Hello,

On Wed 20 Apr 2022 at 03:31PM +01, Matthew Vernon wrote:

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

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Helmut Grohne]

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
Description: PGP signature

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

[Gunnar Wolf]

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
Description: PGP signature

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

[Matthew Vernon]

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
Description: OpenPGP digital signature

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

[Matthew Vernon]

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 when calling for a vote on the ballot]

Thanks,

Matthew

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

[Helmut Grohne]

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

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

[Sean Whitton]

Hello,

On Fri 15 Apr 2022 at 01:14PM -07, Russ Allbery wrote:

> Sean Whitton  writes:
>
>> In this case I believe you need to formally withdraw options A 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.)

I failed to read "or modify", thank you.

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Russ Allbery]

Sean Whitton  writes:

> In this case I believe you need to formally withdraw options A 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)  

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

[Matthew Vernon]

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-7f62-75ba4116b...@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 
resolution

N: None of the above

Regards,

Matthew

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

[Matthew Vernon]

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

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

[Gunnar Wolf]

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!

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

[Sean Whitton]

Hello Matthew,

On Thu 14 Apr 2022 at 04:47PM +01, Matthew Vernon wrote:

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

I think that both of these involve overriding the maintainer, as the
restriction to not include any other binaries if the package Conflicts:
with bin:rename is also to override the maintainer?

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

Thank you for coming up with this text.  Actually, the new procedure is
new to all of us; this is our first use of it.

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

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Matthew Vernon]

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!

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

[Chris Hofstaedtler]

* Helmut Grohne  [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

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

[Dominic Hargreaves]

On Sun, Apr 10, 2022 at 07:37:05PM +0200, Helmut Grohne wrote:
> 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.

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

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

[James Cloos]

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  OpenPGP: 0x997A9F17ED7DAEA6

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

[Helmut Grohne]

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

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

[Helmut Grohne]

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

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

[Dominic Hargreaves]

On Sun, Apr 10, 2022 at 03:17:22AM +0200, gregor herrmann wrote:
> 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.

+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

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

[gregor herrmann]

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
Description: Digital Signature

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

[Helmut Grohne]

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-devel@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

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

[Chris Hofstaedtler]

* Matthew Vernon  [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

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

[Matthew Vernon]

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

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

[Chris Hofstaedtler]

Hello Christoph,

* Christoph Berg  [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

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

[Christoph Berg]

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

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

[Chris Hofstaedtler]

Hello Christoph,

* Christoph Berg  [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

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

[Christoph Berg]

Re: Matthew Vernon
> 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)...

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

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

[Philip Hands]

Christoph Berg  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.
-- 
|)|  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
Description: PGP signature

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

[Matthew Vernon]

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

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

[Sean Whitton]

Hello Chris,

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.

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Christoph Berg]

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

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

[Helmut Grohne]

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

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

[Chris Hofstaedtler]

Hi Helmut,

* Helmut Grohne  [220208 21:23]:
> 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?

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
Description: PGP signature

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

[Dirk Kostrewa]

Dear Sean

On 09.03.22 16:54, Sean Whitton wrote:

Dear Dirk,

On Wed 09 Mar 2022 at 12:59pm +01, Dirk Kostrewa wrote:


Personally, I would still prefer a "rename" entry in the alternative
system with util-linux's rename as default, since util-linux is
installed in every Debian system. I know, the syntaxes of util-linux's
rename and of Perl's rename are incompatible, but a user who wants to
use Perl's rename would probably know its syntax, would have to actively
install its package, and would then choose Perl's rename in the
alternative system.

Right, yes, but unfortunately this is off the table for reasons of
historical compatibility.

okay, I see.



If an entry in the alternative system is not wanted, for me, it would
also be fine to have access to util-linux's rename in any PATH with any
recognizable name. I would then create a soft-link, say,
/usr/local/bin/rename, that points to util-linux's rename.

Hmm, if you are planning to create a symlink, then wouldn't both (A) and
(B) be okay with you?


yes, for me, both would be okay, with a preference for (A), because, 
util-linux's other binaries are also in PATH.


Best regards,

Dirk.

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

[Sean Whitton]

Dear Dirk,

On Wed 09 Mar 2022 at 12:59pm +01, Dirk Kostrewa wrote:

> Personally, I would still prefer a "rename" entry in the alternative
> system with util-linux's rename as default, since util-linux is
> installed in every Debian system. I know, the syntaxes of util-linux's
> rename and of Perl's rename are incompatible, but a user who wants to
> use Perl's rename would probably know its syntax, would have to actively
> install its package, and would then choose Perl's rename in the
> alternative system.

Right, yes, but unfortunately this is off the table for reasons of
historical compatibility.

> If an entry in the alternative system is not wanted, for me, it would
> also be fine to have access to util-linux's rename in any PATH with any
> recognizable name. I would then create a soft-link, say,
> /usr/local/bin/rename, that points to util-linux's rename.

Hmm, if you are planning to create a symlink, then wouldn't both (A) and
(B) be okay with you?

-- 
Sean Whitton

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

[Dirk Kostrewa]

Dear Sean,

first of all: many thanks to the technical committee for taking care of 
my request! This was my first request, and I am really impressed by the 
way this was discussed and handled!


Personally, I would still prefer a "rename" entry in the alternative 
system with util-linux's rename as default, since util-linux is 
installed in every Debian system. I know, the syntaxes of util-linux's 
rename and of Perl's rename are incompatible, but a user who wants to 
use Perl's rename would probably know its syntax, would have to actively 
install its package, and would then choose Perl's rename in the 
alternative system.


If an entry in the alternative system is not wanted, for me, it would 
also be fine to have access to util-linux's rename in any PATH with any 
recognizable name. I would then create a soft-link, say, 
/usr/local/bin/rename, that points to util-linux's rename.


Best regards,

Dirk.

On 08.03.22 20:58, Sean Whitton wrote:

Dear Chris, Dirk,

On Tue 08 Feb 2022 at 09:23pm +01, Helmut Grohne wrote:


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: [...]

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

The ctte discussed this bug at our meeting today and determined that
there are two resolutions to this bug supported by at least one member:

(A) src:util-linux should build a binary package that ships util-linux's
 rename as "rename.ul" somewhere on PATH.

(B) src:util-linux should build a binary package that ships util-linux's
 rename, but does not install it as "rename" anywhere on PATH.
 It is not settled, at present, whether util-linux's rename should be
 provided somewhere on PATH with a name other than "rename".

Option (A) is meant to be (B) plus the additional requirement that it be
rename.ul somewhere on PATH.  Neither option says anything about whether
util-linux's rename.ul should be installed in an Essential package.

Chris, we haven't heard back from you in response to our request for
input quoted above.  We would still very much like to hear what you
think of (A) and (B) and whether you prefer some (C).  If we don't hear
back from you by the time of our next committee meeting in a month, we
will consider voting on (A) and (B).

Dirk, we would be grateful if you would comment on these two
resolutions, but we aren't going to block resolving this bug on hearing
from you.

Thanks both.


--

***
Dirk Kostrewa
Gene Center Munich
Department of Biochemistry, AG Hopfner
Ludwig-Maximilians-Universität München
Feodor-Lynen-Str. 25
D-81377 Munich
Germany
Phone:  +49-89-2180-76845
Fax:+49-89-2180-76998
E-mail:kostr...@genzentrum.lmu.de
dirk.kostr...@lmu.de
WWW:www.genzentrum.lmu.de
***

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

[Sean Whitton]

Dear Chris, Dirk,

On Tue 08 Feb 2022 at 09:23pm +01, Helmut Grohne wrote:

> 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: [...]
>
> 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. [...]

The ctte discussed this bug at our meeting today and determined that
there are two resolutions to this bug supported by at least one member:

(A) src:util-linux should build a binary package that ships util-linux's
rename as "rename.ul" somewhere on PATH.

(B) src:util-linux should build a binary package that ships util-linux's
rename, but does not install it as "rename" anywhere on PATH.
It is not settled, at present, whether util-linux's rename should be
provided somewhere on PATH with a name other than "rename".

Option (A) is meant to be (B) plus the additional requirement that it be
rename.ul somewhere on PATH.  Neither option says anything about whether
util-linux's rename.ul should be installed in an Essential package.

Chris, we haven't heard back from you in response to our request for
input quoted above.  We would still very much like to hear what you
think of (A) and (B) and whether you prefer some (C).  If we don't hear
back from you by the time of our next committee meeting in a month, we
will consider voting on (A) and (B).

Dirk, we would be grateful if you would comment on these two
resolutions, but we aren't going to block resolving this bug on hearing
from you.

Thanks both.

-- 
Sean Whitton

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

[Philip Hands]

Helmut Grohne  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
Description: PGP signature

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

[Helmut Grohne]

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

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

[Christoph Berg]

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

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

[Dominic Hargreaves]

On Tue, Jan 25, 2022 at 09:16:25AM +0100, Chris Hofstaedtler wrote:
> Hi,
> 
> * Sean Whitton  [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".

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

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

[Helmut Grohne]

Hi Chris,

On Mon, Jan 31, 2022 at 09:39:40PM +0100, Chris Hofstaedtler wrote:
> * Helmut Grohne  [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-de...@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

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

[Chris Hofstaedtler]

Hello Helmut,

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

* Helmut Grohne  [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

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

[Helmut Grohne]

Hi,

On Mon, Jan 31, 2022 at 10:11:19AM +, 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

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

[Simon McVittie]

On Mon, 31 Jan 2022 at 10:11:19 +, 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

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

[Matthew Vernon]

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.

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

[Russ Allbery]

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

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

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

[Dirk Kostrewa]

On 25/01/2022 09:16, Chris Hofstaedtler wrote:

Hi,

* Sean Whitton  [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

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.

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

[Chris Hofstaedtler]

Hi,

* Sean Whitton  [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

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

[Sean Whitton]

Hello Chris,

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

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

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

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

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Russ Allbery]

Christoph Berg  writes:

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

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

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

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

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

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

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

[Zack Weinberg]

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

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

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

zw

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

[Chris Hofstaedtler]

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

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

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

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

Chris

(*) "working title"

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

[Sean Whitton]

Hello Christoph,

On Sun 23 Jan 2022 at 10:27PM +01, Christoph Berg wrote:

> 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

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.

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Christoph Berg]

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

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

[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?

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Chris Hofstaedtler]

* Christoph Berg  [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

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

[Christoph Berg]

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

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

[Don Armstrong]

On Sat, 22 Jan 2022, Chris Hofstaedtler wrote:
> * Russ Allbery  [220121 18:11]:
> > Chris Hofstaedtler  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

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

[Chris Hofstaedtler]

* Russ Allbery  [220121 18:11]:
> Chris Hofstaedtler  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

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

[Russ Allbery]

Chris Hofstaedtler  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)  

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

[Chris Hofstaedtler]

Hi,

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

* Christoph Berg  [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

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

[Dirk Kostrewa]

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.