Skip to content

Add explicit Fedora Atomic install methods and harden release installs - #1

Merged
Pat9496 merged 2 commits into
Pat9496:mainfrom
Tuxmint-Open-Source:main
Aug 18, 2026
Merged

Add explicit Fedora Atomic install methods and harden release installs#1
Pat9496 merged 2 commits into
Pat9496:mainfrom
Tuxmint-Open-Source:main

Conversation

@archham

@archham archham commented Aug 17, 2026

Copy link
Copy Markdown
Contributor

Summary

This PR updates the Fedora Atomic / rpm-ostree install flow so users can choose between two supported Topgrade ownership models:

  1. COPR / rpm-ostree

    • installs Topgrade as a layered RPM
    • updates Topgrade through rpm-ostree
    • disables Topgrade self-update
    • restricts the added lilay/topgrade COPR repository with includepkgs=topgrade
  2. Official upstream binary

    • installs Topgrade to ~/.local/bin/topgrade
    • does not add a COPR repository
    • does not layer a package into the OS
    • keeps Topgrade self-update enabled
    • verifies the GitHub release asset before activation

The goal is to avoid presenting either path as universally “right” or “wrong”. Instead, the installer documents and supports both trust/ownership models clearly.

What changed

  • Added Atomic install method selection:

    • --install-method=binary
    • --install-method=copr
  • Added aliases:

    • --binary
    • --copr
  • Interactive Fedora Atomic sessions now prompt when no method is specified.

  • Non-interactive Fedora Atomic sessions default to the binary method.

  • COPR / rpm-ostree remains supported for users who want package-manager integration.

  • The COPR repo file is restricted with:

    includepkgs=topgrade
  • The upstream binary install path now:

    • queries GitHub release metadata with explicit headers/status handling
    • selects the expected Linux release asset
    • verifies the GitHub-provided SHA-256 digest when present
    • checks archive paths before extraction
    • smoke-tests topgrade --version
    • activates the new binary atomically
  • Existing config handling performs small policy repairs with backups:

    • COPR/package-managed installs set no_self_update = true
    • user-local binary installs keep self-update enabled
    • Atomic installs keep rpm_ostree = true
  • Updated English and German README documentation with a comparison of the two Fedora Atomic methods.

Why

The COPR security/trust scope is narrower than a blanket “trust all of COPR”: enabling lilay/topgrade trusts that specific COPR project, not unrelated COPR repositories.

However, the upstream binary path is still useful for users who prefer not to add a persistent third-party RPM repository or layer Topgrade into an Atomic host.

This PR makes that tradeoff explicit:

  • COPR / rpm-ostree = package-manager integration, root/reboot required, trust in the specific COPR project
  • upstream binary = user-local install, no host package layer, trust in upstream GitHub releases

Validation

  • bash -n install-topgrade.sh
  • ShellCheck with --severity=error
  • Simulated Fedora Atomic binary install pinned to v17.9.0
    • release asset selected correctly
    • SHA-256 digest verified
    • binary installed to ~/.local/bin/topgrade
    • topgrade --version returned the expected version
    • config contained rpm_ostree = true
    • self-update remained enabled
  • Simulated Fedora Atomic COPR install
    • COPR repo file installed
    • repo file contained includepkgs=topgrade
    • config contained rpm_ostree = true
    • config contained no_self_update = true
    • reboot message was shown
  • Simulated non-interactive Fedora Atomic install with no method specified
    • defaulted to the binary method
  • git diff --check
  • GitHub ShellCheck passed for push and pull request runs

@Pat9496 Pat9496 left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work!

@Pat9496
Pat9496 merged commit 1786822 into Pat9496:main Aug 18, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants