Spec URL: https://salimma.fedorapeople.org/specs/rust-fts-sys.spec SRPM URL: https://salimma.fedorapeople.org/specs/rust-fts-sys-0.2.8-1.fc39.src.rpm Description: File hierarchy traversal functions (FTS). Fedora Account System Username: salimma
Copr build: https://copr.fedorainfracloud.org/coprs/build/7066109 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2266450-rust-fts-sys/fedora-rawhide-x86_64/07066109-rust-fts-sys/fedora-review/review.txt Please take a look if any issues were found. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
Package looks fine, just one weird thing I noticed in Cargo.toml: > links = "c" This looks wrong. I don't think this crate should claim that it has exclusive rights to link against "c". Or is it a typo and it should be "libc"? Even then, it would be wrong, I think.
PS: You might also want to add a dependency on glibc-devel - looks like <fts.h> that is imported by this package is from glibc.
huh, yes. It sounds like it should be libc which explains the dependency on glibc-devel anyway? I wonder how it got transitively pulled in.
From what I can tell: - remove `links = "c"` from Cargo.toml - add glibc-devel as build dependency and dependency for the -devel package from the cargo docs: > Primarily, Cargo requires that there is at most one package per links value. > In other words, it is forbidden to have two packages link to the same native library. ref. https://doc.rust-lang.org/cargo/reference/build-scripts.html#the-links-manifest-key I'm pretty sure this means that `links = "c"` should be removed from upstream as well, and that this is only working by accident, because not even the "libc" crate (*the* libc bindings) claims to link with libc: https://github.com/rust-lang/libc/blob/main/Cargo.toml