Re: Distribution conditionals in spec files

Vít Ondruch <[email protected]> Wed, 1 Jul 2026 12:52:07 +0200
Newsgroups	gmane.linux.redhat.fedora.devel
Message-ID	<[email protected]>
Dne 30. 06. 26 v 19:18 Michal Schorm napsal(a):
> Daniel's count summary was interesting to me, here's some more:
>
> %{?rhel} ~ 1750
> %{?fedora} ~ 1750
> %{?flatpak} ~ 120
> %{?suse_version} ~ 95
> %{?bootstrap} ~ 85
> %{?epel} ~54
> %{?centos} ~ 24
> %{?eln} ~ 16
> %{?_module_build} ~ 10
> %{?mageia} ~ 6
> %{?snap} ~ 5
> %{?is_opensuse} ~ 4
>   %{?sle_version} ~ 4
> %{?amzn} ~ 1 (condor.spec)
> %{?ubuntu} ~ 1 (tlog.spec)
>   %{?debian} ~ 1 (tlog.spec)
> %{?container_build} ~ 1
>
>
> %{?el10} ~ 12
> %{?el9} ~ 31
> %{?el8} ~ 57
> %{?el7} ~ 51
> %{?el6} ~ 21
> %{?el5} ~ 11


Good numbers! Thanks for collecting those.

On top of these, I would be interested how many times such macros were 
introduced by maintainer of specific component and how often they were 
submitted via PR from somebody else. I remember that I was offered PR to 
introduce some `%{rhel}` and similar conditionals more than once. 
Unfortunately, I failed to find evidence to support this claim :/


>
> In my view, the value of the "SPECfile macro jungle" that makes
> maintenance easier for me - the person who interacts with that SPEC
> the most - is higher than the price occasional visitors with access
> pay. *But* I'm biased by being the maintainer of the packages I do the
> vast majority of the work on.
>
>
> What I always wondered about, when visiting other packages, was *why*
> there is a macro jungle.
> And I always received different answers for different packages from
> different maintainers, based on their own preferences regarding how
> important, for example, RHEL 5 SPECfile compatibility is to them, etc.
> Before making any restrictive decisions, I would *love* to hear from
> all these people about their reasons and justifications: why that
> system is best for them, or what prevents them from cleaning it up. I
> am genuinely interested.


For me, Rawhide is where the development happens. It just runs forward. 
All improvements goes there.

Then there are stable Fedora branches. There goes only selected changes. 
Security fixes - yes, bugfix rebase (teeniest version) - yes, other 
bugfixes - maybe, improvements to something such as file layout - maybe, 
changes due to RPM improvements - likely no, etc. What is common for all 
these changes is that they are easy to cherry pick. There are rarely 
conflicts.

And RHEL is just extension to this. For exam

ple having Ruby 2.5 as a default version in RHEL8, they simply looks 
more similar to ~F28. But there is also hardly any need to backport 
anything from Fedora these days. All in all, the only version of Ruby 
common among Fedora and RHEL are Ruby 4.0 in F44+ and RHEL9+, there is 
where more interaction happens both ways.

BTW even having `rhel` macros in RHEL just makes the spec harder to 
read. As time passes, they become less and less relevant, because what 
can old RHEL version offer to Fedora?

The difference to LLVM IMHO is that LLVM chose to support multiple 
versions in Fedora. There are likely some proc/cons for that decision. 
But I still believe that having single version whenever is better option 
then having multiple versions. Multiple versions of whatever package in 
Fedora are sign of technical debt for me.

Some might view this differently, e.g. that old version(s) makes easier 
to support old RHEL(s). I don't think this is the right strategy 
(despite one of Fedora goals is to be developer workstation of choice).


Vít


> Without that, I'm afraid, we'll only tell each other "I interact with
> SPECfiles in this way, so let's require others to format SPECs so it's
> easiest for *me* to work with them".
>
> --
>
> Michal Schorm
> Senior Software Engineer
> Databases Team
> Red Hat
>
> --
>

-- 
_______________________________________________
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)