Myself and a few others over in Amazon Linux land have been musing for a while
about possible improvements that could be done in Fedora to help make Fedora
and downstream distributions (such as CentOS Stream and Amazon Linux) have an
easier and simpler time having their individual opinionated choices.
The idea of working out something that could sit in Fedora is that then this
can work for Fedora enabling/disabling certain features, as well as making
things like ELN easier, and seed the possibility of an ALN (Amazon Linux Next)
all from the same upstream Fedora packaging repositories. It’d also make things
like EPEL, or a hypothetical Extra Packages for Amazon Linux a whole bunch
simpler as the series of if conditions in a SPEC file could more easily
illustrate intent.
Simply looking at the subset of Fedora packages that make up Amazon Linux 2023,
if you "grep -r '%if.*rhel' */*.spec|wc -l” there’s ~850 matches across ~360
packages, and searching for "grep -r '%if.*amzn' */*.spec|wc -l” there’s ~330
matches across ~240 packages.
One reason we haven’t gone and upstreamed all these if conditions is that it
just seems… hacky. Instead, we’d much rather move to some better mechanism that
ends up with either distro level macros about having features/packages (such as
"%if 0%{?distro_has_gtk1}” or "%if 0%{?distro_feature_gtk1}”) thus making it
useful for Fedora changes in enabling and disabling functionality across
releases.
After all, even across the subset of Fedora packages we have in AL2023, "grep
-r '%if.*fedora} [><=]' */*.spec|wc -l”, i.e. Fedora version specific changes
are at ~240 matches across ~120 packages, and especially for things where it
gates things like python2 support, we could simplify the bconds across a distro
*significantly* and make it *much* easier to turn these on and off across
Fedora releases and downstream distros.
Even for something “simple” like the CPU baseline, the `amazon-rpm-config`
package has the following kind of delta from the `redhat-rpm-config` that sits
in Fedora, which isn’t really being explicit around the intent, and just makes
your head hurt when it comes to merging changes:
-%__cflags_arch_x86_64 %[0%{?rhel} >= 9 ? "-march=x86-64-v2" : ""]
+%__cflags_arch_x86_64 %[(0%{?rhel} >= 9 || 0%{?amzn}) ? "-march=x86-64-v2" :
“"]
….
+# Tuning for aarch64
+%__cflags_arch_aarch64 %[0%{?amzn} ? "-march=armv8.2-a+crypto
-mtune=neoverse-n1" : “"]
A quick sketch of what this all could look like:
1. distro level (in the [amazon|redhat]-rpm-config package or system-release)
“has”
e.g. distro_has_gtk1, distro_has_btrfs, distro_has_jack
This would be used to determine if the functionality is present at all in the
distro, so if you’re building, say in the SDL2.spec it would replace:
%if 0%{?rhel} >= 8 || 0%{?amzn}
%bcond_with jack
%else
%bcond_without jack
%endif
with something like:
%bcond jack 0%{?distro_has_jack}
2. Distro level Feature (in rpm-config or system-release)
e.g. distro_feature_gui
Thus avahi/avahi.spec could replace the following:
%if 0%{?fedora} && !0%{?amzn}
%global WITH_QT3 1
%global WITH_QT4 1
%global WITH_GTK2 1
%endif
%if 0%{?rhel}
%global WITH_MONO 0
%global WITH_QT5 0
%if 0%{?rhel} < 8
%global WITH_PYTHON 1
%endif
%endif
%if 0%{?amzn}
%global WITH_MONO 0
%global WITH_QT5 0
%global WITH_UI_TOOLS 0
%endif
with something more like:
%if 0%{?distro_feature_gui}
%global WITH_QT3 0%{?distro_has_qt3}
%global WITH_QT4 0%{?distro_has_qt4}
%global WITH_QT5 0%{?distro_has_qt5}
%global WITH_GTK2 0%{?distro_has_gtk2}
%global WITH_UI_TOOLS 1
%else
%global WITH_QT3 0
%global WITH_QT4 0
%global WITH_GTK2 0
%global WITH_UI_TOOLS 0
%endif
%global WITH_MONO 0%{?distro_has_mono}
%global WITH_PYTHON 0%{?distro_pkg_feature_avahi_python}
Which is… possibly closer to what a human can parse?
3. Per distro package features (in some include file somewhere? Probably not
the SPEC file itself… maybe an include to it?)
In the Avahi example above, the WITH_PYTHON is distro dependent for some
reason, but is local to the package, it isn’t something that’s distro-wide.
Perhaps a package-local distro file?
i.e. adding in something like the following in the package spec file
Source1234: %{_vendor}-macros.inc
%include %{_vendor}-macros.inc
and then having the include have the %if{amzn/rhel/fedora} <>= VERSION logic
there
Thoughts?
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
