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 example 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 --
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
