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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
