Changes/Rust Crate Packages For Release Branches

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-10-07
• FESCo issue: #2472
• 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.

The long-term goal is to keep source-only crates as up-to-date as possible, so Rust application packagers only have to care about getting their application (and possibly, new dependencies) packaged, and don't have to worry about updating the rest of the Rust stack to compatible versions first.

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, since the buildroot contents can not always be reproduced (since they're only temporarily constructed in ephemeral side tags as part of the current workflow for stable branches).

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

• 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