https://bugzilla.redhat.com/show_bug.cgi?id=2080743
--- Comment #14 from Fabio Valentini <decathorpe(a)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 ;)
--
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
https://bugzilla.redhat.com/show_bug.cgi?id=2080743