On Wed, 26 Feb 2025 at 20:33:46 +0800, Sean Whitton wrote:
> I believe that there is a procedural issue which trumps the substantive
> issue about merging or not merging [/usr/bin with /usr/games]
...
> I would encourage those of you most interested in the merge to do an MBF
> requesting the merge be performed for all the affected packages, and
> then we can undo this again.
You're talking about this in terms of a "merge", but I think both the
existing Policy wording and the change you're proposing are about the
extent to which executables with different functionality in /usr/bin/ and
/usr/games/ are allowed to have the same name, like /usr/bin/pacman (Arch
Linux's package manager) and /usr/games/pacman (a maze-navigation game),
and that's not quite the same thing.
I think it's reasonable to want to forbid/avoid name collisions between
/usr/bin and /usr/games, even without also wanting to merge the two
directories (make one an alias for the other) or otherwise remove
/usr/games as a separate concept.
I am unsure whether it is a good idea to merge or remove /usr/games
(there is lots of reasoning for and against it in #567033), but I do
think we should consider it to be a bug to have two executables of the
same name in the PATH. For example, if one of the pacmans (pacmen?) was
renamed, then I would be able to be confident that running 'pacman'
on a sufficiently modern Debian system would either do what I expect,
or raise an error because the package was not installed, but certainly
not result in getting the other meaning of pacman, regardless of whether
my PATH looks like /usr/bin:/usr/games or /usr/games:/usr/bin.
Similarly I think it would be a consistent and reasonable position to want
to keep /usr/sbin separate from /usr/bin, but require /usr/sbin/foo to be
functionally equivalent to /usr/bin/foo in any situation where both exist.
What I would like to avoid here is having maintainers feel that they
should reject attempts to resolve naming collisions with reasoning like
"this is part of a merge like the /usr-merge and I didn't like the
/usr-merge", because I think resolving naming collisions in the PATH is
a good goal in its own right, independent of whether any more directories
get merged.
> ("may" and "encouraged" here have their official Policy meanings)
>
> --8<---------------cut here---------------start------------->8---
> diff --git a/policy/ch-files.rst b/policy/ch-files.rst
> index 6fda3b1..c2e4700 100644
> --- a/policy/ch-files.rst
> +++ b/policy/ch-files.rst
> @@ -19,6 +19,13 @@ to the ``debian-devel`` mailing list and try to find a
> consensus about
> which program will have to be renamed. If a consensus cannot be reached,
> *both* programs must be renamed.
>
> +There is a exception to the above rules for ``/usr/games``: packages that
> +already install programs to ``/usr/games``, where another package installs a
> +program of the same with different functionality to a different directory on
> +the default ``PATH``, may continue to do so. However, packages must not
> +install any newly conflicting programs to ``/usr/games``, and packages
> already
> +doing so are encouraged to move these programs to non-conflicting names.
> +
> Packages must not install files to paths whose first component is a name
> directly under the file system root and which is a symbolic link to a
> directory of the same name under ``/usr``. That is, packages must not
> install
> --8<---------------cut here---------------end--------------->8---
Do we know that this is only a practical problem for /usr/games, or are
there also collisions between /usr/bin/foo and /usr/sbin/foo in practice?
(Is this something that dumat or debian-dedup can tell us?)
smcv
