Only crates that are published on crates.io may be packaged as Rust libraries, this is a MUST requirement from the Rust Packaging Guidelines: https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_package_sources It appears that the Rust bindings were added with the update to version 2.1.0, because I do not see them discussed in this package's review request. It looks like the Rust library interface of nmstate is unused in Fedora. If this is the case, the simple way to fix this problem might be to just skip calling %cargo_install, and to drop the rust-nmstate-devel and rust-nmstate+default-devel sub-packages again. There's also other problems with the Rust part of the package, for example, not defining the %{crate} macro might cause unintended consequences when calling other %cargo_* macros, and the %cargo_generate_buildrequires call is missing, which is why you appear to be manually keeping the list of BuildRequires up-to-date (though you don't use the correct / up-to-date syntax there).
The `rust-nmstate` will be required by coreos-installer https://github.com/coreos/coreos-installer/pull/864 Anyway, I will submit new package review and remove this subpakage.
I see now that nmstate is actually published on crates.io: https://crates.io/crates/nmstate/ Would it be possible to use the sources from there instead of those from github, and package nmstate as "rust-nmstate"? Then you could definitely keep all the -devel subpackages. The main reasons for not allowing rust-foo-devel packages for Rust code that's not from crates.io are 1) namespace collisions (which is not a problem here, since nmstate is also published there), and 2) relying on standardized source layout and Cargo.toml files in our Rust tooling in Fedora (which *might* be a problem for *you* in the future, if nmstate upstream project starts to use any Cargo.toml syntax or features that aren't supported by our tooling OOTB).
The nmstate has many parts: 1. CLI tool 2. rust crate/library 3. C library 4. Python binding Only the source of rust crate/library is uploaded to crates.io. Let me find out whether we have alternative way to fix this besides request a brand-new package dedicate for `rust-nmstate`.
I can propose a change to the Rust Packaging Guidelines for this case, someting like "If you cannot package Rust sources from crates published on crates.io, but still need to ship Rust crate source code for use in dependent packages, then packaging Rust crates from other sources is only allowed if the crate's source code is *also* published on crates.io *under the same name*, to avoid namespace collisions." I think that would solve the problem for nmstate and nispor?
This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle. Changing version to 37.
(In reply to Fabio Valentini from comment #4) > I can propose a change to the Rust Packaging Guidelines for this case, > someting like > > "If you cannot package Rust sources from crates published on crates.io, but > still need to ship Rust crate source code for use in dependent packages, > then packaging Rust crates from other sources is only allowed if the crate's > source code is *also* published on crates.io *under the same name*, to avoid > namespace collisions." > > I think that would solve the problem for nmstate and nispor? Yes. That would ideal. Maintaining two rpm packages (one for bin files, one for rust-crate) for single project is also OK to me. Then who (robot?) will enforce this?
I've submitted a Pull Request to update the Rust Packaging Guidelines for this: https://pagure.io/packaging-committee/pull-request/1204 I think the exception for "complex" projects that ship Rust crate code that is *also* published under the same name on crates.io should cover these two packages. What do you think?
I noticed the updated `Rust Packaging Guidelines` allows nmstate shipping both bindings/cli/crates in single srpm now: Complex projects with multiple components (i.e. bindings for other languages), which cannot be packaged from sources that are published on crates.io alone, MAY include subpackages for their Rust library interface (rust-$crate-devel, rust-$crate+feature-devel, etc.) ONLY if this crate is also published on crates.io under the same name. Thanks for the help! Closing as not a bug.