On Sat, Jul 13, 2024 at 12:51 AM Carl George <carl@xxxxxxxxxx> 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. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
