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

[Chris Hofstaedtler <zeha@debian.org>]

Hello Christoph,

* Christoph Berg <myon@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