Re: Distribution conditionals in spec files

Vít Ondruch <[email protected]> Tue, 30 Jun 2026 12:13:33 +0200
Newsgroups	gmane.linux.redhat.fedora.devel
Message-ID	<[email protected]>
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.

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=0

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.

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 innovation
>
>
> While 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
>
>

-- 
_______________________________________________
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
OpenPGP_signature.asc (application/pgp-signature, 840 B)