On 10. 01. 22 13:55, Miro Hrončok wrote:
When we invented the %pyproject_buildrequires BuildRequires generator, it
generated build-dependencies. Imediatelly we realized that for several reasons,
also generating the runtime dependencies as BuildRequires is needed:
- they are needed to run the test suite
- they are needed to run an import check
- they make the build fail when runtime dependencies are not found
Hence, %pyproject_buildrequires -r was introduced. This flag is implied by
other flags (-x, -t, -e) but it is not a default behavior.
However, as I've done a fair amount of new package reviews and pull request
reviews to convert packages to pyproject-rpm-macros, I've noticed packagers
have a tendency to forgot the -r flag when:
1) The currently packaged version has no runtime dependencies.
This is currently quite harmless, as when the package is updated with new
dependencies, the packager will notice and add the flag. However, if we ever
have some automation for updates, we better have forward-compatible specfiles.
2) The runtime dependencies are pulled in as transitive dependencies of
manually BuildRequired packages.
For example, if there is `BuildRequires: python3-pytest` and the package
runtime-requires toml, the tests will suceed with pytest 6 (requires toml) but
will error with pytest 7 (as it migrated from toml to tomli).
3) There is not a single check run in %check.
While technically forbidden by the new guidelines, this is not enforced and
hence packages use %pyproject_buildrequires but don't run any tests. This can
result in packages that are updated into an uninstallbale state. I'd rather the
build failed in that case.
Hence, I propose we make the -r flag the default. In case some package needs to
opt-out for legitimate reasons, a new flag would exist to disable it (most
While technically a backwards-incompatible change, I belive the negative impact
should be minimal -- at worst packages that fail to install will now also fail
to build (which is a good thing IMHO).
Given the general agreement here, here it is:
In copr, it broke 3 packages in a way that we want and it broke 2 packages that
were not compatible with -r and I proposed fixes for them.