LLVM Packaging Guidelines

Overview

This guide is intended for packagers working with any of the llvm sub-projects, which include:

• llvm
• clang
• lld
• lldb
• python-lit
• libomp
• libcxx
• libcxxabi

General Development

Please submit pull requests for major changes. This will allow the CI tests to run and give other developers a chance to review.

CI Tests

The goal of the CI tests should be to test integration of llvm packages into the system. Tests for specific upstream bugs are not necessary, but any Fedora bugs that are caused by interactions with another package should have a CI test added when they are fixed.

Rebases

A rebase is an upgrade that changes the major version of LLVM (e.g. upgrading from X.0.1 to (X+1).0.0). For each upstream release we would like to start the upgrade process when the first release candidate is released. Packaging the first release candidate gives us a chance to test and fix issues in Fedora so we can get fixes back upstream before the final release.

Step 1: Creating Compatibility Packages

Create a compatibility packages for clang and llvm for the current release in rawhide. The packages should be called clangX.Y and llvmX.Y, where X.Y.z is the current version of LLVM in rawhide.

You can re-use the existing spec files from the clang and llvm dist-git when creating the compatibility packages. You just need to change the value of the compat_build macro from 0 to 1:

 %global compat_build 1

Step 2: Updating Rawhide

Do local or scratch builds of each llvm sub-project to make sure they build successfully in rawhide. Once you have confirmed that everything works, you can start submitting your builds to Koji. Please make sure to submit builds for all sub-projects as soon as possible to minimize disruptions. If this is not possible, then you will need to request a side-tag from releng so you can stage your builds before adding them to rawhide.

Pocl
Pocl has a runtime dependency on clang, so it needs to be rebuilt during the rebase process.