Diagram of dist-git branches

I want Fedora, but I want control over my dependency streams

Developers have built registries that allow them to build applications composed of specific package release series. What if we took the things that are great about systems like crates.io and PyPI, and delivered those advantages for everything else?

TL;DR In the tradition of software distributions / archives, package registries have become an essential service for software developers. Although they provide similar services, software distributions have not adopted some of the mechanisms that are common in developers' package registries. Those mechanisms allow developers to work asynchronously, eliminating the delays associated with a large-scale synchronized release cadence.


Registries are an essential component of modern development

Most modern languages have an associated package registry that allows developers to share their work. The basic build and installation tools used in many languages integrate with registries to allow developers to seamlessly define packages they require, and the versions that are compatible.

There are several such registries for C and C++, but none with the kind of clear default status that is common for other languages. Among Free Software developers, the operating system’s package manager often serves this function, providing a language-agnostic package registry, but one that varies from system to system, where there is also no clear default. More importantly, where language-specific package management tools typically allow consumers to specify a per-component version selector and allow the developers who publish software to determine what release streams are supported at any given point in time, distribution package managers often flatten each component into one version, which makes the distribution release stream a kind of global selector for all components.

Fedora provides a great toolbox

Fedora maintainers have developed a collection of really useful tools for their work. In the finest tradition of Unix tools, they are small tools that each do one thing well. The beauty of a toolbox is that you can use the individual tools to create a workflow all your own. The curse of a toolbox is that you must use the tools to create a workflow all your own.

dist-git-manager and rpm-build-assist aren’t fundamentally new tools, they’ve simply composed the existing tools into a workflow that’s already common among software developers, but which span various input and output types.

Although they use tools typically associated with the Fedora distribution, dist-git-manager and rpm-build-assist arrange the tools in a structure directed more toward developers’ needs rather than the needs of the distribution.

Asynchronous is faster than synchronous

The difference between dist-git-manager and rpm-build-assist and the repos and workflows typical within the distribution is that repos in the distribution branch for the distribution release rather than branching for upstream project releases. The distribution’s dist-git repos synchronize all of the packages within the distribution. Synchronizing everything can make development work more difficult, because a developer may prefer to update one dependency at a time in order to isolate the changes needed for each update, and because it tends to delay upstream feature releases until the next release of the distribution.

An example

dist-git-manager maintains a registry-style definition of a component, with major and minor branches that function like SemVer selectors as much as possible. For such a component, the “main” branch will always refer to the latest patch release of the latest minor of the latest major release (the thing most people usually mean when they say “the newest release”), while “release-${major}” will refer to the latest minor release stream within a major release series, and “release-${major}.${minor}” will refer to a specific minor release.

With components structured this way, you can easily build a Django application that uses the latest releases of PostgreSQL 18 and OpenSSL 3, without waiting for a subsequent release of Fedora, or you could build a specific minor release of Django while you work on a regression in your app that’s observed on a new Django release. And perhaps you want a container image with specific RPM packages resulting from that build. No problem!

# build-assist.yaml
base: fedora-44-x86_64

build:
  - type: dist-git
    url: https://forge.example.com/myproject/rpms/
    packages:
      - postgresql:release-18
      - python-django:release-5.1
      - openssl:release-3
      - nginx:release-1
      - myapp:main

install:
  type: container
  base_image: registry.fedoraproject.org/fedora:44
  tag: myapp:latest
  packages:
    - python3-django
    - openssl
    - nginx
    - myapp