flatpak-module-tools

#38 BuildRequires mismatch between source-tag and the app build tag
Opened by otaylor. Modified

Open
Close Issue

Currently:

  • evolution in f39-updates has a BuildRequires on /usr/bin/killall (*)
  • evolution in f39-flatpak-app-build has a BuildRequires on /app/bin/killall (*)
  • psmisc in f39-flatpap-app-build is a rebuild that provides /app/bin/killall

(*) This is stray and not needed - killall is now looked for in the path at runtime instead of at build time.

If you try a flatpak-module build-rpms[-local] that includes evolution in the set to rebuild - it dies with:

RuntimeError: Dependency /usr/bin/killall isn't satisfied in resolved packages!

because looks up the BuildRequires for the evolution that it's going to build from the source tag, but then tries to expand them in f39-flatpak-app-build and doesn't find /usr/bin/killall.

The right fix is not entirely clear:

  • Using the BuildRequires from the source tag build seems right - that's what we are going to rebuild, after all - if there's an old build of the same package in f39-flatpak-app-build, it doesn't necessarily have the same BuildRequires
  • Expanding the BuildRequires in f39-flatpak-app-build seems right - we don't necessarily even have a dnf repository for the source tag, and we're going to build against f39-flatpak-app-build anyways.

Things that could help:

  • If there is only one thing being built, skip the build ordering - it's not necessary. This provides a workaround.
  • When we have a local git repo, do the 'fedpkg srpm' step before the build ordering, and use the BuildRequires from that, so that we can fix BuildRequires if that's appropriate. (In the example above, it could be removed. If it wasn't possible to remove, it could be changed to a BuildRequires: psmisc.)

There have been lots of issues with file dependencies in flatpaks, because the correct location ends up depending on whether the dependency is built in /app or is part of the runtime or buildroot, and as more flatpaks are built, this can be something of a moving target. The bin/sbin merge probably doesn't help either, although we'll probably get a better picture with the F41 mass rebuild.

A solution that has come to mind is to stop using file dependencies altogether, specifically by:
* auto-creating virtual provides for all executables in bindir/sbindir, e.g. cmd(foo)
* converting all bin/sbin file dependencies to cmd()
* banning use of file dependencies that aren't guaranteed to be part of the runtime

The drawback is that it will take time; the autogeneration would need to get into rpm or redhat-rpm-config before a mass rebuild, and could only be relied upon starting with the version that branches immediately thereafter. It wouldn't be unconditionally usable in Fedora for another year after that, and for RHEL/EPEL could take years.
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.