On Sat, 03 Jul 2010 13:35:20 +0200, Till wrote:
> 1) To make such run-time deps BuildRequires would be helpful
(because it
> doesn't make much sense to build something for a target that is missing
> something). Several broken deps in old dist branches have been because
> of a discrepancy between Requires and BuildRequires.
If this should be normal, then IMHO rpmbuild should be changed to
use all explicit Requires also as BuildRequires.
It is normal for several automatic dependencies, e.g. for a run-time
library dep you have the corresponding -devel BR in the spec file.
Creating BR for run-time deps can also be helpful in situations where
rpmbuild could not assist you. E.g. an app dlopens an optional libfoo.so.1
at run-time. If you wanted to check for availability of libfoo.so.1 in
the dist at pkg build-time, you would add a BR for the library pkg [and a
guard in %prep or %check].
Along the same line, if you have an explicit Req, possibly even a
versioned one, checking for the required stuff in a BR ensures that
everything you need at run-time, is available in the target dist.
For Python modules there are no automatic deps set by rpmbuild yet,
however. Except for the python(abi) dep.
And there would be drawbacks, too, for a hardcoded "Req => BR" rule.
It would make circular deps impossible: Pkg A requires Pkg A-extras,
and Pkg A-extras BR Pkg A. It would make bootstrapping a dist more
complicated. For some pkgs (e.g. leaf pkgs) it is fine if they are
not available in the buildroot when building a pkg that requires the
leaf pkg at run-time. For other pkgs it is fine if you build them
with an old build tool for a target env that is build upon a newer tool.