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?
--
Yaakov Selkowitz
Principal Software Engineer - Emerging RHEL
Red Hat, Inc.
