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.
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. 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. 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.
- Konrad
--
_______________________________________________
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
