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?
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?
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@lists.fedoraproject.org
-
Vít Ondruch -
Yaakov Selkowitz