On Sat, Jul 13, 2024 at 12:51 AM Carl George carl@redhat.com wrote:
Implementing a cmd() generator seems like just adding technical debt to prop up the core problem.
How about instead...
Option 3: Change the guidelines to state that package names that are identical to command names must own the command in question, or have an equivalent provides. Instead of packagers only trusting a file path dependency on /usr/bin/<name> due to previously being burned by a command moving between packages, they can trust that requiring a command name just does exactly what people would expect it to.
In this case, it would mean that /usr/bin/groff gets moved from groff-base to groff, or alternatively groff-base and groff would merge together.
Coincidentally, the package depending on groff (rubygem-ronn-ng) would also be changed to provide ronn, since it has /usr/bin/ronn.
Maybe we can allow another alternative that it's acceptable for a package with an name identical to a command to just require the package that owns the command, i.e. the current situation where groff requires groff-base which owns /usr/bin/groff, but to me that just feels like poor organization of subpackages.
No, I think a dependency generator would make sense. In general, we want to provide equivalent abstractions when desired. If a file dependency isn't suitable but the packager expresses the intent to include any suitable implementation, then it would make sense to offer an equivalent alternative.
Bash itself has included a dependency generator for shell scripts for a long time, but it results in broken packages because the other side of it (executable() provides) isn't covered. It is worth considering such a generator to solve two problems at once.