Hi Sean, I'm not subscribed, so please Cc me in replies.
On Tue, Feb 25, 2025 at 06:37:19PM +0800, Sean Whitton wrote: > On Thu 20 Feb 2025 at 11:13am +01, Vincent Lefevre wrote: > > > What about existing packages with the same program name? > > > > For instance, > > > > https://packages.debian.org/sid/amd64/lam4-dev/filelist has > > /usr/bin/hcc > > > > and > > > > https://packages.debian.org/sid/amd64/uhexen2/filelist has > > /usr/games/hcc > > > > and I'm quite sure that the hcc programs have different functionality. > > Thanks for the raising this, Vincent, and for the analysis, Michael. > > It sounds like we might need an exception for /usr/games. Please allow me to disagree with the conclusion. /usr/games is meant to be in $PATH (at the choice of the user). Now users may still choose whether they want to list games early or late, but at some point there will be a situation where they prefer a game and a tool such that no order fits. Debian's traditional stance that command names should be unique is a very useful property. It has been upheld e.g. in a ctte ruling on util-linux' rename. I do see that there is significant effort and annoyance involved with renaming games, but the end result is what I value here. Rather I suggest exempting the entire policy item from being considered release-critical in Debian trixie (due to the effort involved) and still aiming for it in forky. I've added d-release@l.d.o to get their feedback on this proposal. I note that the debian-dedup infrastructure is quite suitable for continuously detecting such command conflicts. The dumat tool built on this already has a database of all {,/usr}/{,s}bin files and analyzing it could be turned into semi-automatic reports. Helmut
