From Fedora Project Wiki

Packaging Rust applications/libraries


Add required tools/instructions for packaging applications/libraries written in Rust. Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety.


Current status

Detailed Description

During initial research of SIG about packaging we identified that inability to specify version range dependencies (1.0 <= foo < 2.0) in RPM is main blocker. This problem hits almost every other language ecosystem (esp. NodeJS), but it is not very noticable due to having not more than 2 versions. While packaging some applications we discovered need of having 3 or more versions of same crate.

The most of the work already has been done and users can consume applications without needing to do anything from Rust/Playground COPR repository.

Benefit to Fedora

  • Fedora will be one of first distributions (if not first) who package rust applications/libraries
  • Packagers of other ecosystems/distributions will get ability to express version range dependencies and real example of its usage in various places


  • Proposal owners: Create tool for automatic creation of rpm-spec-file from crate on, create RPM macro for easy packaging, write packaging guidelines.
  • Other developers: RPM developers to add support for expressing version range dependencies.
  • Release engineering: #6889 (a check of an impact with Release Engineering is needed)
  • Policies and guidelines: Packaging Guidelines needs to be written for packaging Rust applications/libraries.
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

N/A (not a System Wide Change)

How To Test

Install tool which is written in Rust and use it (list will be provided when change will be implemented).

User Experience

  • Packagers will be able to package Rust applications/libraries
  • Users will be able to install tools written in Rust from Fedora repositories (i.e. ripgrep)
  • Packagers will be able to write dependency generators for RPM which emit rich dependencies (part of RPM 4.14, but already backported to F27)


  • Support for "with" rich-operator from RPM 4.14 change is required to be implemented.
  • Release engineering tools needs to be adapted to use DNF (because YUM doesn't support rich dependencies)
  • FPC should allow at least with rich operator
  • dnf builddep should be able to work with such dependencies (already implemented for long time)
  • Builders should support that kind of rich dependencies (covered as part of RPM 4.14 change)

Contingency Plan

  • Contingency mechanism: Move implementation to next release (once ready and if possible, backport to old release)
  • Contingency deadline: Final freeze
  • Blocks release? No (not sure)
  • Blocks product? -


N/A (not a System Wide Change)

Release Notes