Bug#1003653: Revision of removal of rename.ul from package util-linux
Hi Chris,
On Mon, Jan 31, 2022 at 09:39:40PM +0100, Chris Hofstaedtler wrote:
> * 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.
I see how you can come to this interpretation, but it is not what I
meant to say. It is true that the proposal avoids the need for a
Conflicts declaration on the package metadata level, but here I was
referring to the differing opinions on how util-linux' rename
implementation should be packaged as "conflict". My thinking was that by
providing the requested tool as an installable executable under some
(non-standard) path, you solve half of the practical problems.
> 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.
Sure. I was aiming at an incremental improvement here. This is not all
black and white. Giving those who need util-linux' rename a way to
obtain it is half the story. Making it the default is a separate step.
Whether that step is to be taken is an interesting question, but I think
that those who are in favour of it, should present a transition plan to
debian-devel@lists.debian.org.
> 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.
I think there is a difference between making that choice prominent and
making it possible. For instance, I am in favour of removing the debconf
choice for /bin/sh. Doing so makes the choice for /bin/sh a lot less
prominent. I am not in favour of removing support for using dpkg-divert
to change what /bin/sh points to. A consequence of that is that if you
encounter a dashism in some shell script, that's still a bug. In that
regard, yes, Debian should make choices for defaults. At the same time,
it should not unnecessarily alienate people who think otherwise. If the
cost for that choice is deemed to high (or not covered by those who are
in favour of it), dropping the choice may become necessary. Given that
practically nothing in the Debian archive uses /usr/bin/rename, I think
that deferring the choice where it points to to users (in a
non-prominent way) is a reasonable thing to do, precisely because
/usr/bin/rename is presently not consistent accross different Linux
distributions.
> 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.
I believe that those who exercise their choice are a very small
minority. The majority will stick with whatever Debian chooses.
A non-prominent choice would be dpkg-divert. As soon as bsdextrautils
ships rename.ul, anyone can use dpkg-divert to change /usr/bin/rename.
The only other piece is requiring that no package uses /usr/bin/rename.
That task can be deferred to choice-proponents by having them send
patches.
Does that make more sense to you now?
Helmut
Reply to: