> These problems have no solution on SRPM level. Unless the spec file is
> preprocessed by rpm, no-one knows whether the package will depend on dynamic
> buildrequires feature or not.
Yes, like I said this is no different from any other data in an src.rpm - it is
only valid for the particular environment it was built in. That doesn't mean
the data there is at all *useless* (our whole buildsystem bases its operation
around it!), one just needs to be careful about interpreting it.
Again the issue here is build versus install. Just like there can be
arch-specific buildrequires in the src.rpm headers that still don't prevent the
src.rpm to be rebuilt on another arch, it'd be equally correct to have a
recorded dependency on rpm *build* capability in the src.rpm. It's just that
rpmlib() dependencies are not appropriate for this task as they track
installability (for example, if the source rpm used a strange compression in
the payload you could not install/unpack the source rpm *at all*), not
buildability.
t would be perfectly fine for an src.rpm to carry a dependency indicating that
in the environment it was built in, it requires an rpm that can handle dynamic
buildrequires,
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/878#issuecomment-538355914
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
