Decathorpe (talk | contribs) (add some feedback from #fedora-rust IRC channel) |
Decathorpe (talk | contribs) (incorporate feedback from devel mailing list (re: Update Policy for source-only packages)) |
||
Line 27: | Line 27: | ||
This includes some CoreOS services, PARSEC, some nice command line tools (e.g. ripgrep, bat, fedora-update-feedback, ...), and parts of the GNOME stack. | This includes some CoreOS services, PARSEC, some nice command line tools (e.g. ripgrep, bat, fedora-update-feedback, ...), and parts of the GNOME stack. | ||
However, because rust crate packages are currently only available on rawhide, packaging rust applications for release branches is difficult and involves more steps than usual. | However, because rust crate packages are currently only available on rawhide, packaging rust applications for release branches is difficult and involves more steps than usual. | ||
=== Build Workflow Changes / Simplifications === | |||
This Change proposal aims to bring Rust packaging in line with the normal packaging workflows in fedora. | This Change proposal aims to bring Rust packaging in line with the normal packaging workflows in fedora. | ||
Line 32: | Line 34: | ||
In particular, the following additional steps will become obsolete: | In particular, the following additional steps will become obsolete: | ||
* use koji side tags for | * use koji side tags for '''every package build''' on release branches | ||
* manual tagging and untagging of koji buildroot contents | * manual tagging and untagging of koji buildroot contents | ||
Instead, rust packages can be built like any other package in fedora. | Instead, rust packages can be built like any other package in fedora. | ||
=== Update Workflow Changes === | |||
I expect that source-only Rust packages (those that don't ship binaries but only source code) will sometimes need to be updated to semver-incompatible versions (e.g. <code>0.8 -> 0.9</code> or <code>1.2 -> 2.0</code>) because dependent '''binary''' packages start depending on those newer versions. | |||
However, since users are usually not expected to install <code>rust-*-devel</code> packages locally (except during local mock builds, i.e. indirect usage in a temporary environment), there should be no negative impact. If there are conflicting dependency restrictions in dependent packages, compat packages for the older crate versions will be created (just like this is handled in rawhide already). | |||
If those version bumps are handled correctly, I don't expect this to cause problems, since Rust crate packages are parallel-installable (source code is namespaced by both the crate name '''and''' the crate version on the filesystem), and the creation of new compat packages is unbureaucratic and does not require package review. | |||
== Feedback == | == Feedback == | ||
There was some discussion in the <code>#fedora-rust</code> IRC channel that this Change will also bring some Rust packages into compliance with their license terms, where this is currently either very hard or impossible. This was incorporated to the | There was some discussion in the <code>#fedora-rust</code> IRC channel that this Change will also bring some Rust packages into compliance with their license terms, where this is currently either very hard or impossible. This was incorporated to the '''Benefit to Fedora''' section. | ||
The Update Policy for source-only Rust packages (packages that don't ship binaries, but only <code>rust-*-devel</code> packages containing source code) was discussed on the devel mailing list. I added a clarification of the expected "''update process''" to the '''Detailed Description''' section. | |||
== Benefit to Fedora == | == Benefit to Fedora == | ||
Line 47: | Line 59: | ||
It will also make it possible to build Rust packages for release branches locally in mock without the need for custom mock buildroot configurations and / or third-party repositories. | It will also make it possible to build Rust packages for release branches locally in mock without the need for custom mock buildroot configurations and / or third-party repositories. | ||
This Change will also make it easier / possible for Rust packages to comply with the terms of certain Licenses, e.g. the GPL, LGPL, or MPL. | This Change will also make it easier and/or possible for Rust packages to comply with the terms of certain Licenses, e.g. the GPL, LGPL, or MPL. | ||
== Scope == | == Scope == | ||
Line 61: | Line 73: | ||
This will require packagers to merge rawhide updates into release branches when appropriate (again, bringing Rust packaging in line with the rest of fedora). | This will require packagers to merge rawhide updates into release branches when appropriate (again, bringing Rust packaging in line with the rest of fedora). | ||
I also expect there to be reduced load on koji due less side tags being in use concurrently, which will benefit all package maintainers in fedora. | I also expect there to be reduced load on koji due to less side tags being in use concurrently, which will benefit all package maintainers in fedora. | ||
* Release engineering: [https://pagure.io/releng/issue/9753 #9753] | * Release engineering: [https://pagure.io/releng/issue/9753 #9753] |
Revision as of 11:59, 15 September 2020
Rust Crate Packages For Release Branches
Summary
This Change proposal aims to enable shipping Rust crate packages (rust-$CRATE_NAME
) on release branches of fedora.
Currently, they are only available for rawhide, which makes building Rust packages for release branches difficult.
Owner
- Name: Fabio Valentini
- Email: <decathorpe@gmail.com>
Current status
- Targeted release: Fedora 34
- Last updated: 2020-09-15
- FESCo issue: <will be assigned by the Wrangler>
- Tracker bug: <will be assigned by the Wrangler>
- Release notes tracker: <will be assigned by the Wrangler>
Detailed Description
Following the general upwards trend in the Rust language's popularity, more and more applications and services in fedora are written in Rust. This includes some CoreOS services, PARSEC, some nice command line tools (e.g. ripgrep, bat, fedora-update-feedback, ...), and parts of the GNOME stack. However, because rust crate packages are currently only available on rawhide, packaging rust applications for release branches is difficult and involves more steps than usual.
Build Workflow Changes / Simplifications
This Change proposal aims to bring Rust packaging in line with the normal packaging workflows in fedora.
In particular, the following additional steps will become obsolete:
- use koji side tags for every package build on release branches
- manual tagging and untagging of koji buildroot contents
Instead, rust packages can be built like any other package in fedora.
Update Workflow Changes
I expect that source-only Rust packages (those that don't ship binaries but only source code) will sometimes need to be updated to semver-incompatible versions (e.g. 0.8 -> 0.9
or 1.2 -> 2.0
) because dependent binary packages start depending on those newer versions.
However, since users are usually not expected to install rust-*-devel
packages locally (except during local mock builds, i.e. indirect usage in a temporary environment), there should be no negative impact. If there are conflicting dependency restrictions in dependent packages, compat packages for the older crate versions will be created (just like this is handled in rawhide already).
If those version bumps are handled correctly, I don't expect this to cause problems, since Rust crate packages are parallel-installable (source code is namespaced by both the crate name and the crate version on the filesystem), and the creation of new compat packages is unbureaucratic and does not require package review.
Feedback
There was some discussion in the #fedora-rust
IRC channel that this Change will also bring some Rust packages into compliance with their license terms, where this is currently either very hard or impossible. This was incorporated to the Benefit to Fedora section.
The Update Policy for source-only Rust packages (packages that don't ship binaries, but only rust-*-devel
packages containing source code) was discussed on the devel mailing list. I added a clarification of the expected "update process" to the Detailed Description section.
Benefit to Fedora
This Change lowers the bar for contributing to the Rust stack in fedora, because it will no longer be a special case that involves additional steps.
It will also make it possible to build Rust packages for release branches locally in mock without the need for custom mock buildroot configurations and / or third-party repositories.
This Change will also make it easier and/or possible for Rust packages to comply with the terms of certain Licenses, e.g. the GPL, LGPL, or MPL.
Scope
- Proposal owner(s):
- one-off change: submit PR to revert the special-case handling for
rust-*
packages in the mass branching releng script - ongoing effort: help package maintainers with merging changes from rawhide (where appropriate) and creating compat packages (when necessary) - this is made easier by the strong SemVer compatibility guarantees of Rust crates
- one-off change: submit PR to revert the special-case handling for
- Other developers:
Initially, there is no impact on other developers. However, as soon as fedora 34 is branched, building Rust applications on that release branch will be easier than without this change. This will require packagers to merge rawhide updates into release branches when appropriate (again, bringing Rust packaging in line with the rest of fedora).
I also expect there to be reduced load on koji due to less side tags being in use concurrently, which will benefit all package maintainers in fedora.
- Release engineering: #9753
Release engineering will need to remove special-case handling of rust-*
packages from their mass branching script before f34 is branched off of rawhide.
- Policies and guidelines:
The Rust packaging Guidelines will need small adaptations.
They are already outdated, so Change owner(s) will update them to the current state of Rust packaging regardless.
- Trademark approval: N/A (not needed for this Change)
- Alignment with Objectives:
The fedora IoT Edition promotes PARSEC, which is comprised of Rust packages - its package maintainers will benefit from being able to update and build those packages faster and more easily for release branches.
Upgrade/compatibility impact
There will be no impact on upgrades from previous fedora releases, since Rust crate packages will only be available for those users for the first time.
If for some reason a user installed rust-*-devel
packages manually after downloading them from the rawhide repositories, they will be gracefully upgraded.
How To Test
Users should be able to build Rust applications for fedora 34 without workarounds or special steps (both in mock locally and in koji - both scratch and non-scratch builds).
User Experience
Users should not notice this change. However, I expect some application updates to be available for release branches faster, since it will be easier for package maintainers to create them.
Dependencies
N/A (this only affects the Rust package stack and has no external dependencies)
Contingency Plan
- Contingency mechanism: untag and block
rust-*
packages in the f34 tag in koji (help from releng / a koji admin required), revert mass branching script changes before f35 branch point - Contingency deadline: Final Freeze (removing packages from koji will no longer be possible after this point)
- Blocks release? No (the initial Change is small and does not negatively affect release process)
- Blocks product? N/A
Documentation
The Packaging Guidelines for Rust will be updated to reflect this Change.
Release Notes
TBD