Changes/Packaging Rust applications and libraries

Packaging Rust applications/libraries

Summary

Add required tools/instructions for packaging applications/libraries written in Rust.

Owner

• Name: Igor Gnatenko (on behalf of Rust SIG)
• Email: ignatenkobrain@fedoraproject.org
• Release notes owner:

Current status

• Targeted release: Fedora 27
• Last updated: 2017-07-06
• Tracker bug: <will be assigned by the Wrangler>

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..

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

Scope

• Proposal owners: Create tools for automatic conversion from crates.io to rpm's spec file, create RPM macro for generation of automatic dependencies, 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)
  • List of deliverables: N/A (not a System Wide Change)

• 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 (already implemented in RPM 4.14)

Dependencies

• 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

Contingency Plan

• Contingency mechanism: Move implementation to next release (once ready and if possible, backport to old release)
• Contingency deadline: N/A (not a System Wide Change)
• Blocks release? ??
• Blocks product? -

Documentation

N/A (not a System Wide Change)