Bug#1003653: Revision of removal of rename.ul from package util-linux
Hi Matthew,
On Fri, Apr 15, 2022 at 08:54:16PM +0100, Matthew Vernon wrote:
> Thanks for the feedback on my previous draft; here's a revised ballot.
Thank you for moving this forward.
> ===Rationale
>
> There are two "rename" programs - the perl rename, and the util-linux
> rename. Debian and its derivatives have shipped the perl rename as
> /usr/bin/rename, whilst other distributions (e.g. Fedora) have shipped the
> util-linux rename thus. The two implementations are incompatible. Users
> might reasonably desire both implementations to be available on the same
> system; they are designed to meet different needs.
>
> Backwards-compatibility (and the lack of a compelling argument that rename
> from util-linux should replace perl rename) means that /usr/bin/rename in
> Debian should remain the perl rename.
>
> Prior to bullseye, util-linux's rename was shipped as /usr/bin/rename.ul;
> Debian's users who wish to use util-linux's rename will expect it to be in
> this location.
>
> ===End Rationale
Thank you and others for this. It looks good to me.
> ===Begin Resolution
>
> The Technical Committee overrides the util-linux maintainer, and requires
> that util-linux's rename should be shipped in a binary package built from
> src:util-linux. If this package Conflicts with the rename package, then it
> should not contain any other binaries.
>
> The Technical Committee further requires that this binary should be shipped
> as /usr/bin/rename.ul
>
> ===End Resolution
>
> A: Override util-linux maintainer, approve entire resoltuion
> B: Override util-linux maintainer, approve only first paragraph of
> resolution
> N: None of the above
I would like to propose two modifications to the ballot.
1. While the former "should" is guarded by "requires", I think the
latter can be read as a recommendation. I therefore propose replacing
it with "must" to make the override more obvious.
2. While option B reads fine to me, option A is a little confusing to
me due to the combination of the naming requirement with the
mentioning of the conflict. Given the rename.ul name, there seems to
be no reason to cause a conflict at all and we can simply require
that. As such I think the options should be fully separated.
===Begin Resolution A'
The Technical Committee overrides the util-linux maintainer, and
requires that util-linux's rename should be shipped as
/usr/bin/rename.ul in a binary package built from src:util-linux. The
package containing rename.ul must not conflict with the rename package
nor divert /usr/bin/rename.
===End Resolution A'
===Begin Resolution B'
The Technical Committee overrides the util-linux maintainer, and requires
that util-linux's rename should be shipped in a binary package built from
src:util-linux. If this package Conflicts with the rename package, then it
must not contain any other binaries.
===End Resolution B'
Do these modifications go with your intents and do you want to accept A'
and B' as a A and B respectively?
In the past discussions on this matter, I was a major force in delaying
a ruling in an attempt to resolve this consensually instead of using
overriding power and recommended overriding as little as necessary.
However, I think that any outcome where we have u-l's rename package
conflict with rename is bad for users, because it makes installation
sets impossible where a user wants u-l's rename together with some
package that happens to depend on rename. This is unlike /usr/bin/python
(which also has mutually incompatible interfaces), because we require
that no package depends on python-is-python3 nor python-is-python2. We
have no such requirement for rename at this time. For that reason, I now
think that any solution involving a conflict with rename is going to
cause problems sooner or later unless we also require /usr/bin/rename to
be shipped by rename-is-prename or rename-is-rename.ul only.
The previous paragraph is not meant to influence available vote options.
It is only given as a guide on the implications of the vote. Possibly,
it would make sense to extend the rationale of option A with a reason
for denying the conflict though.
Helmut
Reply to: