https://bugzilla.redhat.com/show_bug.cgi?id=2362051 --- Comment #5 from Fabio Valentini <decathorpe@xxxxxxxxx> --- Sorry for the delay, was busy with other things last week. There's some issues I found (numbered for easier reference): 1) The FIXME items in the generated spec are not addressed - i.e. the LICENSE tag for the subpackage that contains the statically linked executable needs to be determined and filled in. 2) The patch for Cargo.toml doesn't look entirely correct, especially when looking at the -f flags passed to the %cargo_* macros too: If you want to drop support for the server-side part (and the rouille dependency) - i.e. the "dist-server" and "rouille" features - don't add dummy feature flags for them, just drop them entirely. Having dummy feature flags makes it *look* like the crate supports these features, but anything that would attempt to *compile* it with these flags enabled, that would fail. So better remove the features entirely as to not to lie about what is available and what is not. Patching "default" features should also be considered a "breaking" change, since it changes the behaviour of the Rust crate as packaged compared to the one from crates.io, so that should usually be avoided. In this case, it looks more or less unavoidable, because it would pull in a lot more backends / features / dependencies. It looks like sccache isn't used by any other project as a library. So I would suggest that you just don't build those parts at all (i.e. set `cargo-install-lib = false` in rust2rpm.toml under the [package] table). This will make the packaging for this project a bit easier (and won't supply packages that aren't that useful). 3) You're passing the "-n" flag to %cargo_* macros, but this has no effect if the "default" feature has no dependencies (as is the case due to your patch). You should drop the "-n" flag, since it might cause issues in the future. 4) You're explicitly passing feature flags with "-f dist-client,memcached,native-zlib,webdav", which is a bit strange: You're patching *out* default features with the Cargo.toml patch, but patching them back *in* by passing feature flags on the command line - I would do one of them, not both (i.e. add the features you want enabled as dependencies of the "default" feature instead of the "all" feature). That way the spec file (and rust2rpm.toml config file) would be simpler. 5) You have a "manually created" patch that touches Cargo.toml. This is *not* supported by our tooling - all changes made to Cargo.toml must be made with "rust2rpm --patch", otherwise you might run into weird situations where the generated spec file doesn't match up with the package contents. You would need to apply the bump for the "object" dependency in the same patch as the other Cargo.toml changes. (Yes, I know it is a bit awkward to have to put unrelated changes into a single patch file.) 6) Your ExcludeArch setting is reduntant - drop %{arm} from it. 32-bit ARM hasn't been a supported architecture in Fedora for YEARS. The only 32-bit platform left is i686. And for just using "ExcludeArch: %{ix86}", you don't even need to add a comment or documentation since https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval 7) The project contains some source files that aren't just "Apache-2.0": - src/lru_disk_cache/lru_cache.rs is Apache-2.0 OR MIT - tests/cmake-hip/vectoradd_hip.cpp is MIT The latter looks like it could be excluded from built packages so it shouldn't matter much (especially if you decide to not ship any -devel subpackages as I suggested in point 2). But the first one needs to be documented and reflected in the spec file. -- 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=2362051 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202362051%23c5 -- _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
