F44 Change Proposal: LLVM-22 [SystemWide]

LLVM-22

Wiki

Announced

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary :open_book:

Update all llvm sub-projects in Fedora Linux to version 22.

Owner :open_book:

Detailed Description :open_book:

All llvm sub-projects in Fedora will be updated to version 22. There will be a soname version change for the llvm libraries, and an llvm21 compat package added to ensure that packages that currently depend on clang and llvm version 21 libraries will continue to work.

Other notable changes:
*flang merged into llvm The flang RPMs are now built from the llvm SRPM.

=== Planned Schedule ===
Our plan is to push 22.1.0 into Fedora 44 during the Beta Freeze with a Beta Freeze exception.

We are not planning to push earlier release candidates into rawhide because the library ABI is not stabilized until the final 22.1.0 release.

==== Important Dates ====

  • Jan 16: Begin building LLVM 22.1.0-rc1 in COPR.
  • Jan 27: Begin building LLVM 22.1.0-rc2 in COPR.
  • Feb 3: Fedora f44 branches created
  • Feb 10: Begin building LLVM 22.1.0-rc3 in COPR.
  • Feb 17: Fedora f44 Beta Freeze
  • Feb 24: Begin building LLVM 22.1.0 in Rawhide and 44 side-tags.
  • Feb 24 → Mar 17: Request a Beta Freeze exception for LLVM.
  • Mar 31: Fedora f44 Final Freeze

Feedback :open_book:

Benefit to Fedora :open_book:

New features and bug fixes provided by the latest version of LLVM.

Scope :open_book:

  • Proposal owners:
    ** Build and test release candidates of LLVM 22 in COPR.
    ** Build and test final release of LLVM 22 in koji.
  • Other developers:
    ** Fix build issues found with LLVM-22 or switch their package to use the llvm21 compat libs. The LLVM team will not block Bodhi updates on dependent packages that fail to build or run with LLVM-22. There should be around ~10 weeks between when -rc1 lands in COPR and the Final Freeze for package maintainers to fix issues uncovered with the LLVM-22 update.
  • Release engineering: [Making sure you're not a bot! #Releng issue number]
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with the Fedora Strategy:

Upgrade/compatibility impact :open_book:

Early Testing (Optional) :open_book:

Do you require ‘QA Blueprint’ support? N

How To Test :open_book:

User Experience :open_book:

Dependencies :open_book:

Contingency Plan :open_book:

  • Contingency mechanism: (What to do? Who will do it?) If there are major problems with LLVM 22, the compatibility package provide a way for other packages to continue using LLVM 21.
  • Contingency deadline: Final Freeze
  • Blocks release? No

Documentation :open_book:

LLVM sub-projects in Fedora have been updated to version 22:

  • llvm (now includes flang)
  • libclc
  • llvm-test-suite

Release Notes :open_book:

\n

Last edited by @alking 2025-12-16T15:19:45Z

Last edited by @alking 2025-12-16T15:19:45Z

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

This should actually be a system-wide change, I just forgot to set that initially on the wiki page, but I’ve set it now.

When you say “build in COPR”, what does this entail? Just LLVM and subpackages? Are maintainers of deoending packages supposed to test against COPR builds themselves? That couid mean that LLVM 22 does not see much testing before it hits rawhide, and given your policy and the timing, people will just switch to compat to fix FTBFS before F44 release.

For this proposal, we are just building LLVM 22 release candiates and its subpackages in COPR. If packaging maintainers want to do early testing with LLVM 22 then they can get it from the COPR project.

We do build packages that BuildRequires: clang in COPR approximately every 3 weeks with the latest builds of LLVM from upstream git, so for those packages we try to either fix or file issues ahead of the LLVM 22 release to reduce the chances of FTBFS.

We do expect that most llvm libraries users will switch to the compat package unless they are also doing a new release that support newer llvm.

1 Like

This change proposal has now been submitted to FESCo with ticket #3531 for voting.

To find out more, please visit our Changes Policy documentation.