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?
>