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.
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
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=04) 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.
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.
And these are just a few points.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.
Vít Dne 29. 06. 26 v 20:35 Konrad Kleine napsal(a):
I'm sorry but I have to strongly object after packaging LLVM for years now.We use 0%rhel and 0%fedora and while that seems odd at first it is easy to get used to. You most certainly don't want to get me started on %bcond_without which I also got used to and which I also do like to keep.On Mon, Jun 22, 2026 at 6:48 PM Vít Ondruch <[email protected]> wrote: I for one think that macros such as `%rhel` are antipattern. They * prevent innovationWhile this is true to some degree I haven't seen much innovation except %autorelease in the past years TBH (and %autorelease/%autochangelog is cool). Maybe it is because innovating is hard but I'd say the problem is more deeply rooted in the slow way that old distros are updating RPM. Most of the newer features are only available on newer distros. And I most certainly want to spend my time more on the upstream project than on maintaining different spec file repos. For LLVM for example we still keep fXX repos around but they look very similar to what is in rawhide. In fact, we can build rawhide and RHEL from the same spec file and we can even build daily snapshots and multiple released versions with one spec file which automatically selects which patches to apply depending on the version of LLVM for example. That said, I wouldn't want to go back. This might not be an innovation in RPM but it is truly making our lives easier than before.Don't blame us for not using cutting edge spec file tech when not providing updates of RPM to RHEL.* make the spec harder to read See it blossom :) * make the life harder for proven packages doing some (mini-)mass rebuilds and trying to fix things It has worked in the past with LLVM so I'm good. * tend to age similarly bad to comments in code (granted, there were recently introduced Packit ELN tests, so it is a bit easier to spot some breakage)Definitively not true since we build daily for RHEL using the same spec file that we use for rawhide.- Konrad
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ 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
