In an enterprise distribution, such as RHEL, because of the very long life cycle (10 years or more), there is 2 opposite needs:
- stability, which means keeping the same version for the whole life of the distribution (ex EL-7 still provides PHP 5.4)
- new versions needed by new projects (ex: a lot of projects now require PHP 8)
So, this means we need to be able to distribute alternative versions in a safe way.
This of course also affects my repository, which has the goal to provide more alternative versions and extensions.
This is not a need for Fedora which has a very sort life cycle (6 months), so with no need for newer versions in a stable release.
1. The old time
Until EL-7, the main solution was to create 1 optional repository per version (ex: the RHWAS channel in EL-4).
This was not perfect, mostly working only for newer versions, raising conflicts because 2 versions were available in active repositories.
In EL-5 using different names was tried (e.g. php version 5.1 and php53 for version 5.3), this was a real nightmare, and this has been abandoned.
2. Software Collections
A nice idea appears in EL-6 and EL-7 to provide alternative versions in a separated RPM namespace, installed in a separated tree (/opt), allowing the installation of various versions simultaneously.
Mostly because of some design faults, the community rejected this and the project was abandoned in EL-8 (excepted for newer GCC, in devtoolset).
As initial design issues were fixed, I really appreciate SCL and still use them, and provides them in my repository, see My PHP development Workstation, mostly because I like being able to install various versions simultaneously.
3. Modularity
EL-8 introduced modularity, a new way to manage alternative versions in optional streams. When a stream is disabled its packages are ignored by dnf, when it is enabled its packages are preferred. This works very well for both newer and older versions.
3.1. Everything is module
In EL-8 the idea was to provide everything as modules. This was probably a terrible mistake that caused the community to reject it again.
Indeed, especially for libraries this probably doesn't make sense. This also creates a complex dependency tree, and a very complex build system (MBS).
3.2. Module only for alternatives
In EL-9 everything was greatly simplified. The base system works without modules that are only used for alternative versions (ex: PHP 8.0 by default, but 8.1 and 8.2 are available as modules).
This is probably how modularity should have been used from the beginning. And this works really smoothly. Also, MBS is not really required in this simple scheme, with a simple build configuration being enough.
But it was too late, and the community (mostly the Fedora one) had already killed it.
4. DNF version 5
This is the successor of DNF version 4 which introduces modules. But, as Fedora chose to stop using modules, the needed features are not implemented.
For now, dnf5 only supports enabling/disabling streams, but this is far from usable, and perhaps everything related to modularity will be dropped in the final version.
4.1. Fedora 40
In the upcoming Fedora 40, dnf is still version 4 by default, and dnf5 is also available for test.
Module management still works, despite a small regression which has a workaround.
4.2. Fedora 41
In the future Fedora 41, dnf version 5 should become the default, probably without modularity.
5. My repository
I plan to continue to provide modules for Fedora 40 and probably EL-10, with dnf 4.
I need to think about later versions, having to switch back to the old way (1 repo per version) makes me terribly sad and gives me nightmares.
I've read a proposal to switch back to provide alternative versions under a different namespace. Which seems like switching 10 years back, with a broken solution.
6. Conclusion
Of course, I dream of seeing Modularity support maintained in dnf 5 ;)
I'm disappointed with the bad Fedora community feedback on solutions proposed to solve Enterprise-only needs.
And what a waste of developer energy on these features (SCL and Modularity)
PHP version 8.2.26RC1 and 8.3.14RC1
The packages are available for x86_64 and aarch64.
These Versions fix 4 security bugs (CVE-2024-8925, CVE-2024-8926, CVE-2024-8927, CVE-2024-9026), so update is strongly recommended.
