Hi all,
I recently finished packaging a Rust app for Fedora (bpftop), and I'm looking for advice on managing dependencies going forward. Usually, I'd use Dependabot on GitHub to automatically update dependencies when new crate versions come out. But with Fedora's packaging system, where only one version of each crate is allowed, I'm unsure how to balance this.
A couple of questions:
* Should I consider turning off Dependabot or similar tools because of Fedora's single-version crate policy? If not, how do you all handle these updates?
* Are there any tips for setting up version requirements in Cargo.toml that work better with Fedora's packaging rules? For example, should I be more conservative with version ranges?
I'd love to hear how others deal with this, especially if you've encountered similar challenges.
Thanks in advance for your help!
On Tue, Sep 3, 2024 at 1:46 PM Jose Fernandez me@jrfernandez.com wrote:
Hi all,
I recently finished packaging a Rust app for Fedora (bpftop), and I'm looking for advice on managing dependencies going forward. Usually, I'd use Dependabot on GitHub to automatically update dependencies when new crate versions come out. But with Fedora's packaging system, where only one version of each crate is allowed, I'm unsure how to balance this.
Hi!
"only one version of each crate is allowed" Where did you get this idea?
For many crates, we ship multiple versions, because keeping only *one* version is impossible. The worst example here is probably the "nix" crate which often breaks API - we currently ship v0.14, v0.17, v0.18, v0.20, v0.22, v0.23, v0.24, v0.26, v0.27, v0.28, and v0.29 in Fedora.
A couple of questions:
- Should I consider turning off Dependabot or similar tools because of Fedora's single-version crate policy? If not, how do you all handle these updates?
No, I would not recommend turning off dependabot. However, if possible, I would recommend to configure it to either 1) only bump dependencies in the lockfile (Cargo.lock), and/or 2) only bump dependencies in Cargo.toml if the update is to a semver-incompatible version.
- Are there any tips for setting up version requirements in Cargo.toml that work better with Fedora's packaging rules? For example, should I be more conservative with version ranges?
No, the default in cargo ("SemVer-compatible") is what works best for Fedora packaging too. Our tools are tailored to match cargo defaults where possible.
But sometimes it can be helpful to be more "relaxed" with specifying dependencies. For example, if you know for a fact that your project works with both v0.27 and v0.28 of a crate, don't just bump to "^0.28", but consider using ">=0.27,<0.29" instead.
Fabio
stratisd project has a script that we run nightly that alerts us when Fedora releases a new d semver incompatible version of one of our direct dependencies and then, generally, we bump to that version as well. We think that works pretty well for us.
Our dependencies usually include about 8 crates that are duplicated in our dependency tree. But that list never really increases in size. Some crates leave the list, others enter, some are permanent residents. And some that pass through the list are windows dependencies, that don't matter anyway for Fedora packaging.
- mulhern
On Tue, Sep 3, 2024 at 9:18 AM Fabio Valentini decathorpe@gmail.com wrote:
On Tue, Sep 3, 2024 at 1:46 PM Jose Fernandez me@jrfernandez.com wrote:
Hi all,
I recently finished packaging a Rust app for Fedora (bpftop), and I'm looking for advice on managing dependencies going forward. Usually, I'd use Dependabot on GitHub to automatically update dependencies when new crate versions come out. But with Fedora's packaging system, where only one version of each crate is allowed, I'm unsure how to balance this.
Hi!
"only one version of each crate is allowed" Where did you get this idea?
For many crates, we ship multiple versions, because keeping only *one* version is impossible. The worst example here is probably the "nix" crate which often breaks API - we currently ship v0.14, v0.17, v0.18, v0.20, v0.22, v0.23, v0.24, v0.26, v0.27, v0.28, and v0.29 in Fedora.
A couple of questions:
- Should I consider turning off Dependabot or similar tools because of Fedora's single-version crate policy? If not, how do you all handle these updates?
No, I would not recommend turning off dependabot. However, if possible, I would recommend to configure it to either 1) only bump dependencies in the lockfile (Cargo.lock), and/or 2) only bump dependencies in Cargo.toml if the update is to a semver-incompatible version.
- Are there any tips for setting up version requirements in Cargo.toml that work better with Fedora's packaging rules? For example, should I be more conservative with version ranges?
No, the default in cargo ("SemVer-compatible") is what works best for Fedora packaging too. Our tools are tailored to match cargo defaults where possible.
But sometimes it can be helpful to be more "relaxed" with specifying dependencies. For example, if you know for a fact that your project works with both v0.27 and v0.28 of a crate, don't just bump to "^0.28", but consider using ">=0.27,<0.29" instead.
Fabio
Rust mailing list -- rust@lists.fedoraproject.org To unsubscribe send an email to rust-leave@lists.fedoraproject.org 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/rust@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-
Fabio Valentini -
Jose Fernandez -
the Mulhern