Bug#1003653: Revision of removal of rename.ul from package util-linux
* 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
* 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
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
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
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
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
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 [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
* 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
* 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
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
