Hello Christoph, * Christoph Berg <m...@debian.org> [220406 21:55]: > the TC was discussing this issue at the meeting on Tuesday. > > We acknowledge that there are several possible ways to install it and > steer around the fact that there's also the "perl" rename. Probably > all of these have their warts - the above summarizes the current views > of the TC members: having util-linux-extra conflict with the perl > rename while it contains other binaries is undesirable, and a more > fine-grained solution would be preferred. Or just provide it under the > old name.
> Could you outline the plan you have with bringing rename(.ul) back? > Would it be possible to give us feedback until the end of this month, > so we can wrap it up before the next TC meeting? I see two clear options: A) Keep the status quo ("rename is not part of Debians util-linux"). Very clear, very simple, no work. B) Finish the very old migration. Have util-linux(-extra) ship /usr/bin/rename; perl rename can be prename/file-rename as today, but would need to drop the update-alternatives symlink; versioned Conflicts/Provides/Replaces would probably be needed. I would also suggest having no binary package ship /usr/bin/rename for one release. This is also a very clear option: - All code can in the future assume /usr/bin/rename to have the same interface across distributions. Even Debian code. - Does not need update-alternatives in an Essential package (= no postinst fragment). Less of an issue if /usr/bin/rename will be in util-linux-extra. - One thing less in src:util-linux that needs dh-exec (which is orphaned and I want to get rid of). - Debian can ship both variants under "nice enough" names. I understand this is an unpopular move with current file-rename/prename users. At the same time this option resolves to an outcome that various people before me thought was technically desirable. It needs changes to src:rename, but Dominic is in the loop on this thread and I did not hear technical issues so far against those changes. Maybe it would be a weird thing for the binary package "rename" to not install a program named "rename". Note rgd util-linux-extra: I am trying to reduce the installed size of util-linux, by splitting "not so essential" utilities out of it (and maybe merging a few of the whateverextra packages into a new util-linux-extra). But for at least one release, util-linux-extra would need to be transitively pseudo-Essential (via util-linux). A variant of this option could be to take over the "rename" binary package name by src:util-linux, but that would also be a two-release process, I think. I.e. in bookworm src:rename could introduce a file-rename package, depend on that from the rename binary package, then drop it in bookworm+1, and util-linux could take that binary package name. Or in bookworm+2. Personally I am leaning towards option A) - mostly because we are/were already spending a lot more time on mails than what I think the work of option B) would entail. Also I believe the CTTE does not want to do any of this fine grainted technical detail design work. Chris