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