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?
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@redhat.com 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@lists.fedoraproject.org To unsubscribe send an email to packaging-leave@lists.fedoraproject.org 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@lists.fedoraproject.... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
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.
packaging@lists.fedoraproject.org
-
Carl George -
Neal Gompa -
Vít Ondruch -
Yaakov Selkowitz