This is the correct behavior. Crates from cargo workspaces cannot be packaged as "library" Rust packages (i.e. rust-foo-devel) since there's more than one of them. Library crates MUST be packaged separately from crates.io sources.

Which project is triggering this behavior for you?

Ah, it appears to be nispor.

The problem is that library crates from cargo workspaces can have properties that make them unsuitable for packaging as Rust "library" packages - for example, they can have path dependencies on other members of the workspace (which don't - and cannot - work for Rust packages in Fedora).

The only way to make this work which I can think of would be to check whether the workspace has exactly one crate that qualifies as a library and verify that is has no "path" dependencies. Would this work for your case?

Yes, nispor and nmstate are the cases here where single project provides rust crates, CLI, C library and python library, separating them into multiple package would waste human efforts.

If the fix is too much, you may close this as won't fix, I am OK to use the workaround by removing the workspace top Cargo.toml.

If you want to fix, you may compare pwd with path in cargo metadata.

Right, which is why we've added exceptions to the packaging guidelines to cover cases like this.

So this is a regression that happened with rust-packaging v24 / carfo2rpm. It no longer users the cargo read-manifest command which is deprecated, but only cargo metadata, which always returns information for all crates in the workspace ...

But yes, I think it should be possible to distinguish between a) cargo2rpm pointed at workspace manifest and b) cargo2rpm pointed at workspace member by comparing the paths. I'll try to implement that for the next version so you don't need the workaround forever.

Closing as stale