Since cargo macros now already use a custom rpm profile, maybe there could be another custom profile (rpm-debug, bikeshedding about the name appreciated), which is used instead of the rpm profile if the package contains no binary deliverables? Setting the --profile flag based on the output of %cargo_is_bin() should be possible, I think.

This will need to be implemented in rust-packaging.

Option 1 would be to modify the in the %cargo_prep macro to generate a.cargo/config file that defines both a "release" and a "debug" profile, and then modify %cargo_build / %cargo_install / %cargo_test macros, where the --profile can then be set accordingly.

Option 2 would be to just modify the %cargo_prep macro and adjust the generated .cargo/config file based on the contents of the current crate (i.e. generate a profile close to "debug" mode if there are no binary targets in the crate).

Keeping this ticket open for tracking purposes, even if the correct project to file this would have been https://pagure.io/fedora-rust/rust-packaging.

Thinking about this some more, the easiest way to handle this might be:

• move cargo build, cargo test into subshells similar to cargo_install
• unset RUSTFLAGS in those subshells
• pass --profile rpm if only if debug_package is not set to %nil

Only packages for library-only Rust crates should have %global debug_package %nil, so this is the easiest condition to check for ... and we don't need RUSTFLAGS defined, because the --profile rpm argument for cargo already sets the same options.

PR that implements the idea in the previous comment:
https://pagure.io/fedora-rust/rust-packaging/pull-request/28

This seems to work as expected.

A disadvantage is that testing in release mode can help reveal issues in unsafe code that don’t have practical consequences until stronger optimizations are applied, e.g. https://github.com/milesgranger/blosc2-rs/issues/19.

Ignoring the time/CPU difference, this is probably still outweighed by “Doing optimized builds there […] hides some test failures (no debug assertions, no overflow checks, etc.).”

Marking as stalled and removing from the v27.0 milestone.

This will require bigger changes to the RPM macro side than originally anticipated, and those are not planned before the rust2rpm v27 release.