For nmstate package which shipping both binary and rust crate in single rpm SPEC, I noticed cargo2rpm --path Cargo.toml is-lib is returned 0 even for a library.
cargo2rpm --path Cargo.toml is-lib
I noticed cargo package can expand the Cargo.toml. This is my hack
cargo package
pushd rust/src/lib # Fedora cargo2rpm has problem when working with worksace dependency # we use `cargo package` to generate the expanded Cargo.toml which # is also the one used in crates.io cargo package --frozen --no-verify --target-dir %{_tmppath} tar xf %{_tmppath}/package/nmstate-%{version}.crate \ nmstate-%{version}/Cargo.toml mv nmstate-%{version}/Cargo.toml ./Cargo.toml # Remove worksapce Cargo.toml rm ../../Cargo.toml %cargo_install popd
Hopefully you can patch cargo2rpm to save me from above hack.
I'm not sure why you closed the old ticket and opened a new one. I still don't know how to handle this case better.
You are in two corner cases here (both of which are only OK because there's explicit exceptions for them carved out from the Rust packaging guidelines, one of which was explicitly added because of your package here). I'm not sure the Rust package tooling can (or should!) support all corner cases like this one. I try to make it work for all common situations, but adding (and maintaining!) support for rare (1-2 packages in Fedora) edge cases like this one might not work out from a cost-benefit analysis POV.
I will take another look if I can make this use case work without hacks, but if it's not possible with significant investment of time, then I'll probably say "sorry, I don't get paid for this, please continue using your workaround".
Also, part of your description of the problem is wrong. cargo2rpm operates on the metadata provided by "cargo metadata", and that command contains information not only about the current working directory, but always about the whole workspace. And for workspaces, is-lib must always be false-y.
It might be possible to adapt cargo2rpm to check CWD (i.e. if it's a subdirectory of the workspace and not the workspace root) and adapt the behaviour of both cargo2rpm and %cargo_install in that case ... but I'm not sure how robust that would be, or if it would even work.
I am OK if you close it with won't fix. Just want to share with you my latest hack on this.
I'll take a look if there's an "easy" way to add support for what you need without making it possible for people to shoot themselves in the foot.
Log in to comment on this ticket.