Terra packages and a rolling Fedora repository built as manifests

A repository, not a library

Terra is a rolling-release Fedora repository for all the software you need, and the README's claim is that with Terra you can install the latest packages knowing that quality and security are assured.

The repository this project contains is the manifests for every package in that repository, and the readme is explicit that it is a monorepo containing the package manifests for all packages in Terra. That distinction matters. There is no code to import and no API to call. What lives here is the description of each package: what it is, where it comes from, how it is built, what it depends on, and where it ends up.

The project is operated by Fyra Labs, whose sponsor page is linked in the readme alongside a statement that maintaining Terra requires a ton of infrastructure, package maintainer, submission review and software engineering work. The topic tags give a sense of the shape: anda, dnf, enterprise-linux, fedora, fyra, package, package-repository and rpm.

So the audience for this repository is narrower than a general open source project. It is for people who want to understand or contribute to how Terra is assembled, and for users who want to know what they are installing when they add the repository to their system.

The top-level tree reveals the tooling

The repository layout tells you how the manifests are expressed.

There is an anda.hcl file at the root, and anda and andax directories beside it, which points to the Anda tooling for working with RPM packages and module specifications. A comps.xml file sits at the top level, which is the composition file used to define package groups in RPM distros. There is a .backportrc.json, which is the configuration for an automated backport system, and a .well-known directory, which is how a repository publishes the metadata that services like Repology read to report what a repository contains.

The .devcontainer, .vscode and .zed directories are the usual editor and development environment configuration, and there is a CODE_OF_CONDUCT.md, a SECURITY.md and an AI-POLICY.md, the last of which is a relatively recent addition for a repository in this space.

None of this is in the README, which is why the tree is worth reading on its own. The README covers installation, contributions, documentation, package search and sponsorship, and it does not describe the directory structure or the toolchain. For a contributor, the difference between knowing that a repository has anda.hcl and knowing what the anda and andax directories hold is the difference between guessing and knowing.

Installing on Fedora, including the immutable case

The Fedora install is a single dnf command that points at the repository with repofrompath:

sudo dnf install --nogpgcheck --repofrompath 'terra,https://repos.fyralabs.com/terra$releasever' terra-release

The --nogpgcheck flag and the repofrompath argument are what make this work, since the release package is being pulled from a URL rather than from a configured repository, so there is no key to check against at install time. The $releasever placeholder is substituted by dnf, so one repository definition tracks the running Fedora release.

If you are on an immutable or atomic edition of Fedora, the instructions are different, because rpm-ostree manages the system and the repository file has to exist before the transaction:

curl -fsSL https://github.com/terrapkg/subatomic-repos/raw/main/terra.repo | pkexec tee /etc/yum.repos.d/terra.repo
sudo rpm-ostree install terra-release

That is a meaningful distinction rather than a variant. On an atomic system the base image is replaced wholesale, so adding a repository means a layered package on top, and the readme points at a separate subatomic-repos repository that ships the .repo file for exactly this purpose.

The subrepos exist because conflicts are real

On Fedora you can optionally install the Terra subrepos, and the readme warns that extra care and caution may be needed because some of these packages may conflict with other repositories such as RPM Fusion.

Four are listed. terra-release-extras enables the Extras subrepo, which contains packages that conflict with Fedora packages in some way, such as being a patched version of the same package. terra-release-mesa installs the Mesa subrepo, which contains a patched and codec-complete Mesa. terra-release-nvidia installs the NVIDIA subrepo with NVIDIA drivers. terra-release-multimedia is for multimedia packages, and it carries the strongest warning in the readme: this repository is currently considered unstable and a work in progress.

The design rationale is sound, and it is the same reason RPM Fusion exists. A repository that ships one version of a package cannot coexist with a distribution repository shipping another, so the conflicting packages go into a separate stream that the user opts into explicitly. The subrepo split moves a decision that cannot be automated into a decision the user makes.

The multimedia one being marked unstable is the interesting case, because multimedia packages are exactly where codec licensing sits, and a repository that ships a codec-complete Mesa and a separate multimedia stream is making a deliberate statement about what it will and will not carry.

Enterprise Linux support is EL10 only

The Enterprise Linux story is short and the readme is blunt about its limits. Only EL10 is supported, and not all packages available in Terra are available in Terra EL at this time.

Two commands set it up. The EPEL repositories are required first:

sudo dnf install 'https://dl.fedoraproject.org/pub/epel/epel-release-latest-$releasever.noarch.rpm'

and then Terra EL itself:

sudo dnf install --nogpgcheck --repofrompath 'terra,https://repos.fyralabs.com/terrael$releasever' terra-release

The URL differs from the Fedora one, with a separate terrael path, and the release package carries the same --nogpgcheck and repofrompath pattern.

The two facts to hold onto are the EL10 floor and the incomplete package coverage. EL10 is recent, so a team on EL9 has no path here. And the gap between what Terra ships for Fedora and what it ships for EL means that a package list you build against the Fedora repository is not automatically valid on the Enterprise Linux side.

The readme also carries a Repology badge for the rawhide repository, which is a useful operational signal: Repology tracks the repository's content and status over time, so a badge showing drift or errors is a more honest health check than the marketing claim about quality and security.

Contributing means going through a review process

The contributions section points at three documents and a chat.

There is the Contribution Guide, an FAQ and a set of Guidelines, all hosted on the docs site, and the readme invites anyone with questions about contributing to join the chats linked from the community page. The guidelines link in particular suggests that adding a package is a process rather than a pull request, and the sponsor paragraph confirms the shape of that process by naming submission review as one of the things maintaining Terra requires.

The readme also lists the ways to find packages. pkgs.org, hosted at fedora.pkgs.org, and Repology both provide a list of the packages available in Terra, you can dnf search for all packages, and you can search in graphical app stores for packages with AppStream MetaData once Terra is installed.

That last point is worth a sentence, because it tells you how the repository is integrated with the desktop. AppStream metadata is what makes a package appear in a graphical software centre with an icon and a description rather than as a bare package name, and a repository that publishes it is participating in the desktop's package discovery rather than only existing for the command line.

For finding out what is actually available, Repology and pkgs.org are the faster route, since the repository itself is where you would go to change something rather than to check something.

Editorial conclusion

Terra packages is a good fit for a Fedora user who wants newer packages than Rawhide offers without running Rawhide itself, since the repository tracks a rolling Fedora base and is built from manifests in a repository you can read, and the subrepo split gives a way to take only the parts you want. It is a poor fit if you are on a non-Fedora distribution, since Enterprise Linux support is limited to EL10 and the readme says not every package is available there, and a poor fit if you need a support commitment, since this is a rolling repository whose content changes underneath you. Before adopting, read the contributing guide and the guidelines to understand what a package has to go through, check the repository status badge for your release, and treat the multimedia subrepo as experimental, since the readme describes it as currently unstable and a work in progress.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. Project website
4. README
5. terrapkg/packages on GitHub