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

[Chris Hofstaedtler <zeha@debian.org>]

Hello Helmut,

Thank you for the very detailed research (which I have removed
in my reply below).

* Helmut Grohne <helmut@subdivi.de> [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