On Wed, Jul 1, 2026 at 5:42 AM Konrad Kleine <[email protected]> wrote: > > Hi Vit, > > On Tue, Jun 30, 2026 at 12:14 PM Vít Ondruch <[email protected]> wrote: >> >> I took your response as and invitation to look at repo / llvm.spec and I >> have made a few observations: >> >> 1) The spec is ~4000 lines. In roughly first 300 lines I have tried to >> count, the RHEL conditions are responsible for ~30 additional lines. Not >> sure if can extrapolate it, but hey, there are likely hundreds of lines >> which could be shaved off. > > Where's the benefit of not having the RHEL conditions in the Fedora rawhide > spec file? If somebody wants to contribute to LLVM, that's fine. If they > cannot test for RHEL or know about it, that's fine as well. We can tweak > things later for as long as Rawhide still works. During snapshot builds we > can see what breaks and fix things up after the patch landed in rawhide. >> >> 2) There are 4 RHEL8 patches irrelevant for Fedora. They are several hundred >> lines long. If I wanted to e.g. contribute rebase (or simply do some >> experiments with LLVM), I would likely needed to deal with that to do the >> job properly > > No. > > We rebase every day in the LLVM snapshots. So usually when a new release is > out, all one has to do is update the version and that's it. By then the rest > of the spec file is already prepared for the new version. In that sense we're > backwards and forward compatible. LLVM is a heavy package to do > experimentation with IMHO. In the past we've introduced a Profile Guided > Optimization (PGO) step for example. Btw. in the past (e.g. F37) the now big > LLVM downstream monorepository was split into 13 packages (bolt clang > compiler_rt flang libclc libcxx libomp lld lldb llvm mlir polly python-lit). > If you wanted to do an update to a newer version of LLVM, you'd have to > update all of these packages which was always a pain, especially if you build > them in the wrong order. Without changelogs, the old spec files had 2400 > lines of net code (excluding 227 lines of comments). The current rawhide > llvm.spec file uses %autochangelog so we don't have to remove changelogs. We > have 3307 lines in rawhide (excluding 743 lines of comments) right now. > Overall from f37 to rawhide today we have a 27% growth rate excluding any > comments. Here's how this comes about: > > Patch logic > > we choose automatically which patch to apply based on the LLVM version (first > two digits) and the patch number (last two digits of the patch number) > > More lua functions to compensate for > > out of memory errors, > logic to install compat files, or man pages > > More build conditions > General project growth upstream > Complexity of CMake setup > > Take per-runtime configuration for libclc for example > > More files to install > PGO logic >> >> 3) There are old Python constructs around. If I was for example measuring >> how we are looking with migration of old construct to newer, this is skewing >> the statistics: >> >> https://sourcegraph.com/search?q=context%3Aglobal%20repo%3A%5Esrc.fedoraproject.org%2F%20%25py3_build&patternType=regexp&sm=0 > > Let's talk about what exactly you want to change please and we can work it > out I'm sure. >> >> 4) Similarly, if Fedora decided to mass migrate to %autorelease / >> %autochangelog, such spec file would not make it easy and some LLVM >> maintainer would likely need to be involved. > > We already use %autorelease and %autochangelog . We made the move last year > in August. > (https://src.fedoraproject.org/rpms/llvm/c/38695d7c00f54e4fb6beb0047acdf5f63d854037?branch=rawhide). > And later in e43d81023e69f1dbe95b927192ba376127f272a8 and > 4a9d3ea6cffcd4cf66c6cd1a4585412cea8205e2 we fixed things up so that this will > work on RHEL as well. >> >> 5) There are PR such as >> https://src.fedoraproject.org/rpms/llvm/pull-request/615. It could have been >> 9 lines if it was just Fedora, much easier to read and review. Seeing just >> the Rawhide tests in the PR, I am not sure how regular Fedora contributor >> could come with such PR respecting all the RHEL versions. > > If this only introduced the cfg_file_content for Fedora that would have been > fine. We could have taken it from there to respect RHEL. While you mention it > would be easier if there was only rawhide. Can you imagine how much harder it > is to maintain three different RHEL versions and Fedora and try to make them > align closely and not screw up over 13 packages which originally LLVM was > composed of? >> >> And these are just a few points. > > These were worth to discuss I think. >> >> So with all due respect, it is honorable achievement that there is such >> .spec file which can build on all Fedoras / RHELs. But to me there is price >> *others* pay for this unfortunately. > > We can agree that it is hard to change something in the llvm spec file if you > don't know your way around. That's the nature of LLVM, not the spec file. > We've made things substantially easier for everybody to not have to patch 13 > spec files but just one. The interconnection between packages is now much > more visible. Updates are taken care of on a daily basis, so literally nobody > needs to come in and rebase LLVM. Lately packit does rebase PRs for us for us > and it mostly only updates the version and the sources file and it usually > works. That's it. Given that LLVM has ~500 commits per day, this is quite > cool IMHO. All patches are already prepared for the new version since we were > building it in the snapshots for months before and addressed fixes months > before. > > With the current architecture we're also giving much more back to the LLVM > community because we link our daily snapshot reports on github to upstream > PRs and issues so things are more transparent and people can react quicker > and fixup things in LLVM upstream. You could say that they see if they break > Fedora which wasn't possible before. Because of this short delay of a day or > so, we have better quality and little to no crunch time when a new release is > out. >
And yet, we still can't get LLVM into Fedora in time for mass rebuilds and struggle to have a good integration story across the entire Fedora community. > So in one way we can make the downstream spec file be user-friendly to > beginners or mass changes or people who want to change python macros or we > can make our lives easier and keep up with the head of LLVM and the > development that happens there. We opted for the latter and try to respect > the mass changes happening every so often. Here's an example of a recent > change that will slowly happen upstream and that will affect RHEL only: > There's a python dependency (myst) coming that we cannot provide on RHEL. You could just... ship it in Fedora and RHEL and not do weird things instead. MyST is a Sphinx extension, and Sphinx is available in RHEL. It is totally reasonable to ship and I would expect other projects would be interested in extended Markdown-based documentation powered by Sphinx. > It will be needed to build man pages. In order to still be able to build RHEL > we decided that it is best to build the man pages upstream and include them > in the LLVM release. Then we can include them along with the assets from the > sources file. While this might not be needed for Fedora we still implemented > it in rawhide because it made sense. This manages to screw us later, though, because if backports that bring functionality or update documentation are done, the man pages aren't going to be updated if the patches touch them. MyST basically never gets added to Fedora because you took a myopic shortcut. Heck, the only reason I knew about it is because you just mentioned it. > In one way you could argue that this myst dependency is new and we're holding > back the llvm rawhide spec file because there was no change needed. But on > the other hand we avoided an additional build step of the man pages (in a > package that already consumes lots of resources and time) and things become a > bit more streamlined. We aim for little to no differences between the OSes to > be able to focus our time on LLVM itself rather than on the packaging too > much. We've already put years of experience and work into the llvm spec file > repository and it paid off for us. And hey, we don't bite so any contribution > is welcome, even when it won't work in RHEL. The only thing we must hold back > are things we don't see too much value in. For example using a newer form of > bcond_without might look good on paper but the price to pay in order to do > the next RHEL update is simply too high. > Or you could request it to be backported to RHEL so that nicer constructs can be used. I did this for "%autosetup -C", and now it's available in CentOS Stream 10 and will be part of the next RHEL 10 minor. The reason for this complexity is simply because people don't ask for these things because they think it can't be done, despite many examples to the contrary. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
