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
