From Fedora Project Wiki
< Changes
No edit summary |
No edit summary |
||
| (15 intermediate revisions by 3 users not shown) | |||
| Line 2: | Line 2: | ||
== Summary == | == Summary == | ||
Add required tools/instructions for packaging applications/libraries written in Rust. | Add required tools/instructions for packaging applications/libraries written in [https://www.rust-lang.org/ Rust]. Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety. | ||
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. --> | <!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. --> | ||
| Line 13: | Line 13: | ||
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --> | <!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --> | ||
* Email: ignatenkobrain@fedoraproject.org | * Email: ignatenkobrain@fedoraproject.org | ||
* Release notes | * Release notes ticket: [https://pagure.io/fedora-docs/release-notes/issue/106 #106] | ||
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo) | <!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo) | ||
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address> | * FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address> | ||
| Line 23: | Line 23: | ||
== Current status == | == Current status == | ||
* Targeted release: [[Releases/ | * Targeted release: [[Releases/28|Fedora 28]] | ||
* Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} | * Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} | ||
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page | <!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page | ||
| Line 33: | Line 33: | ||
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development | CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development | ||
--> | --> | ||
* Tracker bug: | * Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1475132 #1475132] | ||
== Detailed Description == | == Detailed Description == | ||
During initial research of SIG about packaging we identified that inability to specify version range dependencies (<code>1.0 <= foo < 2.0</code>) 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.. | During initial research of SIG about packaging we identified that inability to specify version range dependencies (<code>1.0 <= foo < 2.0</code>) 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 [https://copr.fedorainfracloud.org/coprs/g/rust/playground/ Rust/Playground COPR repository]. | |||
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --> | <!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --> | ||
| Line 45: | Line 47: | ||
== 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 92: | ||
* 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 98: | ||
* 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 106: | ||
* 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 124: | ||
--> | --> | ||
[[Category: | [[Category:ChangeAcceptedF28]] | ||
<!-- 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 --> | ||
Latest revision as of 15:03, 2 March 2018
Packaging Rust applications/libraries
Summary
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.
Owner
- Name: Igor Gnatenko (on behalf of Rust SIG)
- Email: ignatenkobrain@fedoraproject.org
- Release notes ticket: #106
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
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)