Repository navigation
feat: package OpenShell for Fedora #3511
Description
User Story
As a Red Hat engineer helping productize OpenShell for internal RPM/entitlement use, and as an OpenShell contributor, I want OpenShell available as a properly reviewed Fedora package, so Fedora users and downstream consumers can install it through their normal package manager instead of install scripts or third-party COPR repos.
Problem Statement
OpenShell has no path into Fedora today. The repo carries a root-level openshell.spec intended for Fedora/EPEL, but it isn't build-ready — it consumes externally prebuilt binaries rather than compiling from source, which Koji/mock cannot support. Getting into Fedora also requires resolving vendored-dependency policy questions (~600 vendored Rust crates), a bundled library with a system equivalent (Z3), and a vendored crypto stack that bypasses system crypto policy.
Impact / Why This Matters
Several Red Hat product efforts want a supported, source-buildable path to OpenShell RPMs; Fedora-first is one of two distribution paths being evaluated internally, and landing in Fedora is more durable and community-aligned than an internal-only channel. Today the only RPM path is a hand-rolled internal COPR build — not Fedora-reviewed, not broadly redistributable.
Proposed Design
Track the concrete engineering work as linked child issues, work through them roughly in dependency order, then proceed through Fedora's package review process once the spec is review-ready.
Acceptance Criteria
-
openshell.specbuilds viarpmbuild/mockfrom source with no network access after%prep - Vendored dependencies are license-audited and correctly reflected in
License: - Z3 and vendored-crypto bundling concerns are resolved or explicitly documented
- A package review request is filed and approved via Fedora's New Package Process
- OpenShell builds successfully in Fedora Rawhide
Alternatives Considered
- Internal-only RPM distribution (via an internal COPR/entitlement channel) — already in progress in parallel by a separate internal team; faster to a shippable artifact but doesn't benefit the broader Fedora/community ecosystem and adds a second packaging surface to maintain long-term.
- Container-image-only distribution (status quo) — doesn't meet the needs of consumers who want a system-package-manager-installable binary.
Child Issues
- bug: openshell.spec %build does not compile from source #3512
- bug: openshell.spec packages Python protobuf stubs without generating them #3513
- feat: reproducible source/vendor tarball generation script for Fedora packaging #3514
- bug: openshell.spec Version/Release does not follow Fedora conventions #3515
- feat: aggregate vendored-crate licenses into an accurate SPDX License: tag #3516
- feat: unbundle Z3 from gateway runtime packaging #1969
- feat: document vendored-crypto bundling justification for Fedora packaging #3517
- feat: add CI job to build/validate openshell.spec #3518
Checklist
- I've reviewed existing issues and the architecture docs
- This is a design proposal, not a "please build this" request
Activity
politerealism commentedon Sep 21, 2026
Duplicate of #3509 (created by a failed
gh issue createcall that apparently still created the issue before erroring on issue-type assignment). Consolidating all tracking into #3509 — closing this one.