Anaconda is the installer under Fedora, RHEL and CentOS

The installer most RPM distributions ship

Anaconda is described in the first line of the readme as the OS installer used by Fedora, RHEL, CentOS and other Linux distributions. That framing explains both its scale and its constraints. It is not a general purpose installer that a small project can adopt lightly, it is the installation program of several major distributions, and it has to run in an environment where the target disk is not yet a running system.

The topics the repository is tagged with describe the shape of the work: automated installation, graphical user interface, text user interface, and Python 3. The readme is short, which is consistent with the audience, since the substance is in the documentation site at anaconda-installer.readthedocs.io rather than in the readme itself.

The repository listing shows how large the thing is. Alongside the entry point anaconda.py there is a pyanaconda/ package, a dracut/ directory, a widgets/ directory, data/, scripts/, docs/, po/, tests/ and a dockerfile/ directory. There is also an autotools build with configure.ac, Makefile.am, acinclude.m4 and autogen.sh, plus an anaconda.spec.in for RPM packaging and a pyproject.toml for the Python tooling.

That combination of a Python application, a dracut integration and an RPM spec is the shape of a component that other distributions assemble rather than something they rewrite.

Two front ends over the same core

The repository tags point at both a graphical user interface and a text user interface, and the layout supports that. The pyanaconda/ directory holds the Python package, anaconda.py is the entry point at the top level, and the widgets/ directory sits alongside it.

The reason a distribution installer needs two front ends is practical rather than stylistic. The graphical installer runs when there is a display and a desktop environment available, which is the normal case for a person installing a laptop. The text interface is the fallback for machines with no graphics output, for remote installations over a serial console, and for automated flows where a script has to drive the same decisions.

The readme does not document the internal split between the two, and the documentation site is the place to look for it. What the repository layout does show is that the interface layer and the core are separated into distinct directories, which is what makes a second front end possible without duplicating the storage and partitioning logic.

For an adopter, the practical question is how much of that core you can reuse. Anaconda talks to the target machine's storage, network and bootloader configuration, and that is the part that is expensive to rebuild.

Autotools, a spec file and a branch configuration

The build system is worth understanding, because it explains how one codebase serves several distributions and several release branches at once.

The classic GNU tooling is present, with configure.ac, acinclude.m4, Makefile.am and autogen.sh. Alongside it sits anaconda.spec.in, a template RPM spec file, and branch-config.mk with a matching branch-config.mk.j2 template, plus a .branch-variables.yml file. The .j2 suffix on the template makes the mechanism explicit: the branch configuration is generated from a template rather than hand written, so a new release branch gets its configuration from variables instead of from copy and paste.

The packaging metadata is just as deliberate. There is an rpminspect.toml and an rpmlint.toml, which are the configuration files for the RPM inspection and linting tools, and a .packit.yml with a .packit.yml.j2 template, which is how the project tells Packit how to build the package in a Fedora Copr. The Copr build status badge in the readme points at the rhinstaller Anaconda Copr, so the distribution build happens automatically rather than on a maintainer's laptop.

For someone who needs to build a customized Anaconda, that is the part to take away. The RPM spec, the branch configuration and the Copr recipe are the three files that define what your installer actually contains.

The Python tooling lives in pyproject.toml

The Python side of the project is configured in a pyproject.toml file, and it is short enough to read in one go. The test configuration comes first:

[tool.pytest.ini_options]
testpaths = ["tests/unit_tests"]
python_files = "test_*.py"
python_classes = "*TestCase *Test"
python_functions = "test_*"

[tool.ruff]
include = ["pyanaconda/**/*.py", "tests/**/*.py", "scripts/**/*.py"]
extend = "tests/ruff/ruff.toml"

[tool.darker]
formatter = "ruff"

Three things stand out. The unit tests live in their own directory, tests/unit_tests, which means the default pytest run does not pick up the slower integration style tests. The file, class and function naming patterns are fixed by convention, so a new test file has to be named test_*.py and a test class has to match *TestCase or *Test to be collected.

The linting uses ruff, with its own configuration file under tests/ruff/ruff.toml that the root configuration extends, and the include list is restricted to the three Python trees that matter, the main package, the tests and the scripts. The formatter setting says darker with ruff as the formatter, which is the tool that formats only the lines a commit actually changed rather than rewriting whole files, a choice that keeps diffs small on a codebase this size.

A .coveragerc, a .codecov.yml, a .pep8speaks.yml and a .shellcheckrc complete the tooling picture, along with a translation-canary/ directory.

Translations are a first class concern

The readme gives translation its own paragraph, and there are two separate pointers. There is a bug report and feature request link to Bugzilla at bugzilla.redhat.com, and there is a translation link to the Fedora translation site for the Anaconda project.

The repository supports that with a po/ directory and a translation-canary/ directory. The po/ directory is where gettext catalogues live, and the translation canary is a mechanism for catching untranslated strings, which matters for an installer because every user visible string in the wrong language is a string a person cannot read during installation.

The badges at the top of the readme make the same point in badge form, with a translation status badge pointing at the Fedora translation platform alongside the build status, documentation status and coverage status badges.

This matters for anyone planning to run their own branded installer. The translation workflow is already set up against an existing platform, so a fork does not have to invent a mechanism, but it also means the strings and their catalogues are maintained as part of a wider distribution effort, and a fork that diverges in wording has to keep its own catalogues in step.

Kickstart, not Anaconda, is the answer for automated installs

The readme has a short section that answers a question many people arrive with, and the answer is not what you would guess from the repository name.

For automated installation, the readme points at Kickstart and its documentation at pykickstart.readthedocs.io. In other words, the unattended installation format is a separate project, and Anaconda is the program that executes what Kickstart describes.

That division is worth understanding before you invest in either. Kickstart is the declarative answer file format that lets you specify the installation steps in a file, and Anaconda is the engine that reads those steps, drives the storage and network configuration and applies them. The repository topics confirm the split by listing automated installation as a separate concern from the graphical and text interfaces.

The practical consequence is that an unattended installation pipeline has two moving parts, and you need both. The readme's pointers to the Kickstart documentation and to the Anaconda contributing guide are the two entry points for getting that right.

Several branches ship at once

The release history shows how many branches are alive. Three tags appear in the recent list: anaconda-46.3 on 2026-10-20, anaconda-45.30 on 2026-10-16, and anaconda-40.22.3.58 on 2026-10-16. Two different major version lines were updated within days of each other, and the third is a patch release in a much older line.

That pattern makes sense for an installer, since it is tied to the distributions and kernels it installs. A newer branch tracks current platform work, while older branches keep servicing distributions and hardware that are still in use, and the .branch-variables.yml and branch-config.mk files are the mechanism for keeping the differences between those branches under control.

The last push was on 2026-10-20 and the repository is not archived, so development is current. The licence is GPL-2.0, with the text in the COPYING file, which is the expected choice for a system component that distributions ship inside their own products.

For a project that wants to track upstream, the practical advice is to pick a branch deliberately. Following the default branch when your distribution ships an older line means picking up changes aimed at a different platform target.

Editorial conclusion

Adopt Anaconda when you are building a Linux distribution image or an unattended installation flow, since it already handles the hard parts of booting into a limited environment and driving a storage, network and partitioning workflow. Skip it if you want a lightweight installer for a small appliance, because this is a full distribution installer with a large Python codebase and a long dependency chain, and for automated installs the project points you at Kickstart rather than at Anaconda itself. Before you build on it, read the documentation at anaconda-installer.readthedocs.io, check which branch you are targeting, since several are released in parallel, and verify that your media and dracut integration match the kernel and initramfs you ship.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. rhinstaller/anaconda on GitHub