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