https://bugzilla.redhat.com/show_bug.cgi?id=2440297
--- Comment #4 from Ben Beasley <[email protected]> --- (In reply to Basil Crow from comment #3) > Thanks for fixing that, Ben. I'd actually like the package to be named > "ptools", since it is a user-facing CLI, the same way the "clippy" package > is named "clippy" and not "rust-clippy". I think this would help users find > it, since they don't care about the implementation details of it being > implemented in Rust. However, the packaging tool I used to convert the crate > into a Fedora package specification named it "rust-ptools." I'm not sure > what the Rust packaging experts would recommend here. Remember the distinction between source and binary package names. If you plan to continue to package this from the crates.io source and maintain it using rust2rpm, then you must keep the *source* package named as rust-ptools, https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_package_naming, but note that the *binary* package in your submission is named ptools, so this is the package name that users will see: "dnf install ptools" will already work. Since you sensibly chose not to package the crate library, which doesn’t appear designed for external use, you have the *option* to package from the GitHub source archives instead of the crates.io crates, in which case ptools would be the more appropriate source package name, https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_non_crate_rust_projects. Note that you won’t be able to use rust2rpm if you go this route. Several new releases have appeared in the past few days. When you update to 0.2.9, which also includes pauxv, pflags, prun, psig, pstop, and pwait executables, you will need to figure out how to avoid conflict with the pflags executable from python3-linux-procfs; see https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/. Since the names of the commands are so short and simple, you will need to continue to check carefully for conflicts as upstream implements more tools. The other thing I noticed is that there is a test that fails on s390x, our sole big-endian architecture: https://koji.fedoraproject.org/koji/taskinfo?taskID=142545286. Indeed, this is clearly an endianness bug: running 1 test test test::test_parse_ipv4_sock_addr ... FAILED failures: ---- test::test_parse_ipv4_sock_addr stdout ---- thread 'test::test_parse_ipv4_sock_addr' (878) panicked at src/bin/pfiles.rs:608:9: assertion `left == right` failed left: 1.0.0.127:5432 right: 127.0.0.1:5432 Ideally you could work with upstream to get this fixed. -- 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=2440297 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202440297%23c4 -- _______________________________________________ package-review mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
