https://bugzilla.redhat.com/show_bug.cgi?id=2368362
--- Comment #13 from Ben Beasley <[email protected]> --- (In reply to Noa Resare from comment #10) > I have one questio: As part of my new release I had a look at the latest > releases of all the dependencies and updated anyhow and thiserror, the to > crates that had updates. This broke the build in copr since these specific > patch releases are not available. What is the preferred way to handle this? > I felt a bit backwards to create a new point-release with downgraded > dependencies, so instead I created a patch for the .spec file and checked it > into > https://github.com/nresare/rpm-packaging/blob/main/ssh-agent-client-rs/ssh- > agent-client-rs-1.1.2_deps_rollback.patch > which copr uses to build the .src.rpm. > > What is the preferred way to deal with this? If a very recent version of a dependency is needed “just because,” that its, because somebody updated lower bounds as a routine upstream maintenance activity, or a bot like renovate or dependabot is aggressively bumping lower bounds upstream, then patching them to allow slightly earlier versions is a very reasonable choice. However, when patching Cargo.toml, instead of something like [package] extra-patches = [ { number = 10, file = "ssh-agent-client-rs-1.1.2_deps_rollback.patch"}, ] you should do something like: [package] cargo-toml-extra-patches = [ "Allow slightly older patch releases of thiserror and anyhow", ] and then run "rust2rpm -p" to patch Cargo.toml interactively. If you need to carry the same patch to subsequent updates, you can do "rust2rpm -r" and it will try to reapply/rebase it. ----- If you really do need an update, you can set the bugzilla ticket for the update (assuming anitya/the-new-hotnesss has filed one) to depend on the tickets for the dependency updates. That helps the maintainer see that there is actually a reason to prioritize an update. ----- In some cases, filing a PR for the update may be helpful, if you’re willing to do due diligence to make it helpful and easy to review: - Check the source diff, e.g. for thiserror, https://github.com/dtolnay/thiserror/compare/2.0.16...2.0.17 or https://diff.rs/thiserror/2.0.16/thiserror/2.0.17/Cargo.toml - Check the changelog, e.g. https://github.com/dtolnay/thiserror/releases/tag/2.0.17 - Do a local mock build with "fedpkg --release rawhide mockbuild -- --postinstall". This checks that no feature metapackages have unsatisfied dependencies. - Deal with any interconnected packages; for example, rust-thiserror and rust-thiserror-impl must always be updated together in the same side tag. Test them together: something like "mock -r fedora-rawhide-aarch64 --clean && mock -r fedora-rawhide-aarch64 -i ~/fedora/rust-sig/rust-thiserror-impl/results_rust-thiserror-impl/2.0.17/1.fc44/rust-thiserror-impl*.noarch.rpm && fedpkg --release rawhide mockbuild --no-clean --no-cleanup-after -- --postinstall" - If a package will be updated across SemVer boundaries, analyze whether a compat package will be required or whether (ideally) dependent packages can be safely patched, preferably offering these patches upstream. A half-baked PR that would break dependent packages is not very useful, but a high-quality PR can be. -- 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=2368362 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202368362%23c13 -- _______________________________________________ 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://pagure.io/fedora-infrastructure/new_issue
