From Fedora Project Wiki
< Changes
No edit summary |
No edit summary |
||
| Line 45: | Line 45: | ||
== Scope == | == Scope == | ||
* Proposal owners: Create | * Proposal owners: Create tool for automatic creation of rpm-spec-file from crate on crates.io, create RPM macro for easy packaging, write packaging guidelines. | ||
<!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
| Line 90: | Line 90: | ||
* Packagers will be able to package Rust applications/libraries | * Packagers will be able to package Rust applications/libraries | ||
* Users will be able to install tools written in Rust from Fedora repositories (i.e. [https://github.com/BurntSushi/ripgrep ripgrep]) | * Users will be able to install tools written in Rust from Fedora repositories (i.e. [https://github.com/BurntSushi/ripgrep ripgrep]) | ||
* Packagers will be able to write dependency generators for RPM which emit rich dependencies ( | * Packagers will be able to write dependency generators for RPM which emit rich dependencies (part of RPM 4.14, but already backported to F27) | ||
== Dependencies == | == Dependencies == | ||
| Line 96: | Line 96: | ||
* Release engineering tools needs to be adapted to use DNF (because YUM doesn't support rich dependencies) | * Release engineering tools needs to be adapted to use DNF (because YUM doesn't support rich dependencies) | ||
* FPC should allow ''at least'' <code>with</code> rich operator | * FPC should allow ''at least'' <code>with</code> 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 Plan == | ||
| Line 102: | Line 104: | ||
* Contingency mechanism: Move implementation to next release (once ready and if possible, backport to old release) | * Contingency mechanism: Move implementation to next release (once ready and if possible, backport to old release) | ||
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --> | <!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --> | ||
* Contingency deadline: | * Contingency deadline: Final freeze | ||
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --> | <!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --> | ||
* Blocks release? | * Blocks release? No (not sure) | ||
* Blocks product? - | * Blocks product? - | ||
| Line 120: | Line 122: | ||
--> | --> | ||
[[Category: | [[Category:ChangeReadyForWrangler]] | ||
<!-- When your change proposal page is completed and ready for review and announcement --> | <!-- When your change proposal page is completed and ready for review and announcement --> | ||
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | ||
Revision as of 12:41, 6 July 2017
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 tool for automatic creation of rpm-spec-file from crate on crates.io, 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)
- 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 (part of RPM 4.14, but already backported to F27)
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
withrich 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? -
Documentation
N/A (not a System Wide Change)