https://bugzilla.redhat.com/show_bug.cgi?id=2080743
--- Comment #14 from Fabio Valentini decathorpe@gmail.com ---
It seems to be quite strange that the package "compiles" just fine even on the ppc64le machine.
Well, of course it does. The code that depends on ring is not compiled by default (that's how conditional compilation works). It would only fail of the feature that depends on the "ring" dependency is enabled (either in this package or in any dependent package).
It seems to me rust-ring-devel should be architecture specific and should not provide dependencies on architectures where it is known to not build.
That would be ideal, yes. But as I noted, this is not possible to do due to limitations of RPM and Fedora build infrastructure.
This way it cascades some workarounds on dependent libraries and has to be solved only by leaf applications, which actually build compilable code.
This is the reality we have to deal with. Though I think I know how to work around this (similar to how the "rust-cpufeatures" package is built - skip compiling the code and running the test suite on certain architectures, but provide the source code on *all* architectures, even on those where it doesn't work).
It is not just fault of domain project that rust-ring-devel does not work on some architectures. It should not require workarounds on other packages, which just consume it. Let alone farther in chain. Then the crate dependencies should ensure only people including optional features development headers would get issues.
Yes, yes, "should" this, "would" that ... if my grandma had wheels, she would be a bike ;)