Fedora keeps its promises. Twice a year the community ships a major new version packed with fresh software, security fixes and architectural tweaks. But few users see the machinery behind those downloads. A recent technical post lays out the full sequence from a packager’s git commit to the finished ISO, OSTree commit and cloud image. The author, who writes under the handle supakeen, titled it The Fedora 45 Sausage Factory. The piece offers a clear, unvarnished view of the process as it stands for the upcoming October 2026 release.
The story begins in dist-git. Every package lives in its own git repository on src.fedoraproject.org or the newer Forgejo instance. A packager pushes a commit containing an RPM spec file, patches and a sources file that references tarballs stored elsewhere. Tools such as fedpkg turn that commit hash into a build request. Nothing ambiguous. The exact source state is recorded. Reproducibility starts here.
Koji, the build system that has served Fedora since version 7, takes over. Its hub-and-spoke design keeps every build isolated. Builder daemons poll for work, spin up a fresh Mock chroot, compile the package and return results. Tags define buildroots and destinations. Inheritance lets maintainers layer one release on another without duplication. Koji also orchestrates image builds through plugins for Kiwi, Image Builder and OSTree tasks. Clean rooms matter. A stray library installed last week cannot change tomorrow’s output.
But a freshly built RPM does not reach users automatically. For branched releases it enters Bodhi, Fedora’s update manager. Packagers file updates. Testers and automated systems supply karma. Critical-path packages face stricter rules: fourteen days in testing, higher karma thresholds, gating through Greenwave and ResultsDB. Rawhide behaves differently. Many packages go straight to stable unless they trigger a policy. The system tags builds, composes repositories and pushes them when criteria pass. Stability comes from friction.
Pungi ties the pieces together. The compose tool freezes a package set from a Koji tag early in the run. That snapshot never changes even if new builds arrive mid-process. Comps XML defines groups. Variants XML decides which groups belong in Workstation, Server, Silverblue or the Everything repository. Everything and Server gather full package sets. Most spins produce only images on top of that base. The design keeps metadata consistent and auditable.
Boot images come next. Lorax traditionally creates the minimal boot.iso that launches Anaconda. For Fedora 45 the community approved a switch to image-builder and osbuild for both the boot.iso and Atomic Desktop media. The change proposal documented on the Fedora Wiki lists ModernizeBootISO and Build disk images for Atomic Desktops with image-builder among dozens of accepted updates. Simon de Vlieger and Neal Gompa own the boot.iso work. The move promises more consistent pipelines built on JSON manifests and sandboxed stages. Osbuild already powers many artifacts; extending it reduces maintenance overhead.
Kiwi still builds the majority of live media, cloud images and Vagrant boxes. Its XML descriptions live in a dedicated repository organized by teams. Each build runs inside a Mock environment that substitutes the frozen compose repositories. The result: every cloud image matches the exact package set chosen for that milestone. Container base images, WSL packages and generic qcow2 files follow the same path.
Atomic Desktops take yet another route. rpm-ostree composes versioned filesystem trees from treefiles written in YAML. The workstation-ostree-config repository supplies layered includes that pull in comps groups for GNOME or KDE while adding ostree-specific packages and exclusions. A script called comps-sync.py keeps the lists aligned. The output is an OSTree commit that clients replicate atomically. Silverblue, Kinoite and the growing list of atomic spins all ship this way. Users receive transactional updates rather than a pile of RPMs.
Productmd generates the metadata files that describe every compose. Composeinfo, images and repository data follow a standard format. Mirrors and download pages rely on it. The entire artifact set becomes self-describing.
Fedora 45 carries dozens of technical upgrades. The GNU toolchain moves to gcc 16.2, binutils 2.47, glibc 2.44 and gdb 17.2. Python advances to 3.15. Perl reaches 5.44. LLVM lands at version 23. RPM 6.1 arrives with enforced signature checking by default. A new change sets allow_vendor_change to false in DNF 5 defaults. Versioned libgit2 packages replace the unversioned ones; dependents must now declare exact compatibility. These updates appear in the official ChangeSet wiki page.
Performance gains also arrive. A system-wide proposal will build packages for the x86-64-v3 baseline alongside the older v1. When DNF detects a capable CPU it will install the faster binaries automatically. Owners Lleyton Gray, Kyle Gospodnetich and Owen Zimmerman outlined the work on the Fedora Discussion forum in April. They noted that Enterprise Linux Next already builds the v3 set successfully. Compatibility remains. Older systems continue to receive v1 packages. The discussion highlighted infrastructure costs and a small percentage of users whose hardware lacks AVX2, yet the change passed. Modern CPUs should notice the difference in compute-heavy workloads.
Security and privacy improvements appear throughout. A proposal restricts ptrace for unprivileged users by default. Another adopts kmscon as the virtual terminal console, moving away from the kernel’s fbcon. The GRUB EFI for Confidential Computing change introduces a minimal bootloader package. It contains only the modules required for UEFI Secure Boot, UKI support and BLS files. Peter Robinson and others explained that the smaller attack surface helps keep TPM PCR measurements stable. Remote attestation benefits. The full GRUB remains the default. Phoronix covered the approval in an article published in June. The piece quotes the desire to avoid multiple bootloaders and notes that systemd-boot was not chosen.
Storage and installation also evolve. Stratis integration in Anaconda received approval. Users will be able to install directly onto Stratis filesystems through both Kickstart and the web-based Cockpit interface. Vojtech Trefny owns the change. A separate self-contained proposal adds web-based remote installation for Atomic Desktops. Administrators boot with a kernel parameter, then finish setup from a browser on another machine using HTTPS and a PIN. Phoronix reported the filing just days ago in its July coverage. The feature targets Silverblue, Kinoite and similar variants.
Package management receives attention too. DNF 5.4 appeared recently, continuing the transition from DNF 4. Bodhi, Pungi and Koji already interact with it. The vendor-change default adjustment prevents unexpected swaps between repositories unless explicitly allowed. Reproducible builds become an expectation; the project aims for 99 percent of packages to produce identical output from the same source.
These modifications do not happen in isolation. Each change proposal travels through FESCo review. Contingency plans exist. Many list beta freeze as the deadline for revert. The Fedora 45 schedule, according to Wikipedia’s release history page, targets a final release on October 20 after a beta in late August or early September. Delays occur when blocker bugs appear. Fedora 44 slipped its original target in April, a reminder that even mature processes face surprises.
The sausage-factory description makes one fact plain. Volunteers, Red Hat engineers and downstream contributors coordinate across git, bug trackers, mailing lists and IRC. No single company dictates the timeline. Policies evolve. The migration from Pagure to Forgejo continues. Image Builder replaces older Lorax paths. Osbuild stages multiply. Yet the core loop stays recognizable: push source, build cleanly, test, compose, ship.
Outsiders sometimes picture Linux distributions as simple aggregators of upstream code. The Fedora process shows otherwise. Hundreds of packages must align. Installers, bootloaders, image builders and update tools interact. A tweak to RPM signature enforcement ripples through Bodhi gating and Pungi composes. The x86-64-v3 change touches Koji, DNF, Pungi and redhat-rpm-config at once. Coordination costs time. The payoff appears in a release that works across bare metal, virtual machines, confidential guests and container hosts.
Recent Phoronix reporting adds color. One July article noted Fedora 45’s plan to begin phasing out the in-kernel crypto userspace API. Another highlighted the approved Stratis work. The steady flow of change proposals keeps the project moving. Not every idea lands. Discussions on the forum sometimes reveal tension over build resources or security trade-offs. The x86-64-v3 thread included concerns about repository layout and potential path-hacking vectors, yet the owners addressed them and the change advanced.
Documentation keeps pace. The sausage-factory post invites corrections by email. Its author notes that the boot.iso section will likely need updates before final release. Such transparency helps new contributors understand where their patches ultimately travel. A packager who only ever runs fedpkg build now sees the full downstream path to a cloud image or Atomic commit.
Fedora’s next version will ship Python 3.15, a faster x86 baseline for many users, stricter defaults on debugging and signatures, modernized image pipelines and better confidential-computing support. The pieces fit together because of the machinery described in that weblog post and the hundreds of approved changes tracked on the wiki. The process looks messy up close. It produces consistent, auditable releases that millions of users and organizations trust. And the next cycle already waits in Rawhide.
WebProNews is an iEntry Publication