Rust March 2024

rust@lists.fedoraproject.org

3 participants
2 discussions

Advise on packaging a Rust app
by Antoine Tenart 20 Dec '24

20 Dec '24

Hello, [Resending as first email was rejected; wasn't a member of the list] We'd like to package a Rust application for Fedora, Retis[1]. We currently distribute it in COPR[2] because we can't easily follow the Fedora Rust packing rules at the moment but that is far from being perfect (on all levels). Don't get me wrong, I think the packaging rules make sense; but those are a high entry barrier for projects with multiple unpackaged complex dependencies (recursively). We wrote a plan with detailed steps to get there, https://github.com/retis-org/retis/milestone/13. It's basically divided into the following directions: - Take over / upgrade some outdated dependencies. - Package the missing dependencies in Fedora. Some are easier than others to package / maintain. - Remove the use of other dependencies. There are a few issues to overcome (packaging complex dependencies takes time, I think we have a dep of a dep w/o a license, etc) but most importantly I think the concern is with maintenance; especially when it's not trivial. All that of course will be quite an effort so we thought we should ask for your input and advises on if this is the right direction or if you have some comments? Also we're wondering if there's anything that could ease the process or make the delay shorter (eg. vendoring *some* deps temporarily)? The above also raises an additional question: any additional dependency added upstream, if not already packaged and non trivial, could gate upcoming releases from being packaged. Gating upstream development on downstream packaging doesn't look right and I guess those kind of issues are just expected (we already have one coming); but wanted to ask just in case :) Thanks! Antoine [1] https://retis.readthedocs.io/en/stable/ [2] https://copr.fedorainfracloud.org/coprs/g/retis/retis/

2 8

Firecracker 1.7 crate updates
by David Michael 24 Mar '24

24 Mar '24

Hi, Firecracker 1.7 was released with dependencies on the following API-compatible crate versions. Can these updates be pushed? Let me know if you want me to handle any of them. - clap-4.5.1 (currently 4.5.3 is available) - semver-1.0.22 Since the topic of their dependency update schedule came up before, they run dependabot on the main development branch every Monday. However, this time they made the stable branch early so updates were stopped a month ago. This version also drops dependencies on versionize and versionize_derive which have no other users. Should I retire them from f40+rawhide when the update is pushed? Are there special concerns with retiring Rust crates? Thanks. David

2 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

Rust March 2024