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. On Wed, Apr 3, 2024 at 3:11 AM Vít Ondruch <vondruch@xxxxxxxxxx> wrote: > > Just for the sake of transparency, this proposal is related to this PR: > > https://src.fedoraproject.org/rpms/rubygem-ronn-ng/pull-request/2 > > where we had some argument with Yaakov 😊 > > > Vít > > > Dne 03. 04. 24 v 10:05 Vít Ondruch napsal(a): > > Generally, I am still in favor of `%{_bindir}/foo`. > > > > Anyway, I don't think that option 2 scales (unless we would go with > > something smarter, such as `%{cmd:foo}` which would actually expand to > > `(/usr/bin/foo or /app/bin/foo)`). > > > > This leaves us with the `cmd(foo)` which IMHO should be easy to generate. > > > > > > Vít > > > > > > Dne 03. 04. 24 v 1:31 Yaakov Selkowitz napsal(a): > >> The packaging guidelines currently allow file dependencies in /etc, > >> /usr/bin, and /usr/sbin to be used in spec files. However, this can > >> pose a problem for Fedora Flatpak builds, where an ever-growing number > >> of packages are being built for flatpaks in /app which breaks such file > >> dependencies. > >> > >> (A separate problem is posed by the use of installation path macros in > >> file dependencies, but that is already disallowed; see further > >> discussion in https://pagure.io/packaging-committee/pull-request/1346 ) > >> > >> Regarding /usr/bin and /usr/sbin file dependencies, generally the > >> intention is "require whichever package that installs this command in > >> $PATH". In such a case, it doesn't really matter if it's in /usr/bin > >> (for normal RPM builds, or for packages in the flatpak runtime, or for > >> flatpak buildroot-only dependencies) or in /app/bin (from packages > >> built for flatpaks). While the package name providing that command > >> could be used, package contents can vary over time, and maintainers > >> want to avoid having to track that. > >> > >> Common examples are /usr/bin/groff (groff-base) and /usr/bin/pod2man > >> (perl-podlators), both of which are now built in /app to support perl > >> for flatpak apps. > >> > >> Option 1 would be for either rpm or redhat-rpm-config to generate e.g. > >> cmd(foo) virtual provides for /usr/bin/foo or /usr/sbin/foo (and for > >> flatpaks, also for /app/bin/foo or /app/sbin/foo). Packages would then > >> [B]R: cmd(foo), and (eventually) file dependencies in /usr could be > >> dropped entirely. (The "cmd" name is just an example and could of > >> course be changed.) > >> > >> The major disadvantage of this approach is the implementation time > >> involved. Even if it were to be implemented prior to the F41 mass > >> rebuild, it would not be usable across all stable Fedora versions until > >> the middle of F43 development (after F40 EOL), and wouldn't be > >> compatible with EPEL for a long time (although that could be shortened > >> somewhat if it gets into c10s before the last mass rebuild). It would > >> also create a lot more virtual provides, but would be a big step closer > >> to dropping file dependencies entirely. > >> > >> Option 2 would be to boolean dependencies, e.g.: > >> > >> [Build]Requires: (/usr/bin/foo or /app/bin/foo) > >> > >> This would avoid the implementation delay but is much more verbose. > >> > >> Thoughts? > >> > -- > _______________________________________________ > 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 -- Carl George -- _______________________________________________ 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
