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 p
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
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 contai
> ===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 di
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
>
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 contain
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
> pa
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 h
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 d
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 i
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&B and
>> then propose another ballot.
>
> Minor procedural point: the person proposing the options can also freely
> modify them, so you didn't
Sean Whitton writes:
> In this case I believe you need to formally withdraw options A&B and
> then propose another ballot.
Minor procedural point: the person proposing the options can also freely
modify them, so you didn't technically have to withdraw them and could
instead just alter the option
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 formal
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
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
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 co
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 holiday
* 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'
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.
>
> > Further
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
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' r
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
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 re
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
> r
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; per
* 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
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 re
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
> >Co
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.
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 ab
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 in
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
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-ex
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
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
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 d
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 E
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, th
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
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
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,
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
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 packa
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 t
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.
> >
>
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 re
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 uncontrover
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 submi
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 not
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
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".
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,
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
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
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 shi
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
* 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
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 id
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 "
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
* 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, i
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 numb
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 pac
* 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
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 s
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 alternative
> 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 alte
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 ever
68 matches
Mail list logo
