Remi's RPM repository - Blog

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)

Version 8.2.0alpha1 is released. It's still in development and will enter soon in the stabilization phase for the developers, and the test phase for the users.

RPM of this upcoming version of PHP 8.2, are available in remi repository for Fedora 35, 36 and Enterprise Linux 7, 8, 9 (RHEL, CentOS, Alma, Rocky...) in a fresh new Software Collection (php82) allowing its installation beside the system version.

Je vois régulièrement passer des questions sur l'utilisation d'anciennes versions de PHP sur Fedora (qui fournit la 8.3) ou de versions plus récentes sur RHEL / CentOS / Alma / Rocky (EL-8 fournit la 7.4 / 8.0 / 8.2, EL-9 fournit la 8.0 / 8.1 / 8.2).

Un développeur utilisant PHP a souvent besoin de tester son travail avec plusieurs versions. Donc voici un petit descriptif de la station de travail que j'utilise quotidiennement

La version 8.1.0alpha1 est publiée. C'est actuellement la phase de développement, mais la phase de stabilisation va bientôt commencer pour les développeurs, et celle de test pour les utilisateurs.

Les RPM de cette prochaine version de PHP 8.1, sont disponibles dans le dépôt remi pour Fedora 33, 34 et Enterprise Linux 7, 8 (RHEL, CentOS, ...) dans une nouvelle Software Collection (php81) permettant son installation en parallèle de la version système.

La version 8.0.0-alpha1 sera prochainement publiée. C'est actuellement la phase de développement, mais la phase de stabilisation va bientôt commencer pour les développeurs, et celle de test pour les utilisateurs.

Les RPM de cette prochaine version de PHP 8.0, sont disponibles dans le dépôt remi pour Fedora 31, 32 et Enterprise Linux 7, 8 (RHEL, CentOS, ...) dans une nouvelle Software Collection (php80) permettant son installation en parallèle de la version système.

La version 7.4.0-alpha1 sera prochainement publiée. C'est maintenant la phase de stabilisation qui commence pour les développeurs, et de test pour les utilisateurs.

Les RPM de cette prochaine version de PHP 7.4, sont disponibles dans le dépôt remi pour Fedora 29, 30 et Enterprise Linux 7, 8 (RHEL, CentOS, ...) dans une nouvelle Software Collection (php74) permettant son installation en parallèle de la version système.

La version 7.3.0 Alpha1 vient juste d'être publiée. C'est maintenant la phase de stabilisation qui commence pour les développeurs, et de test pour les utilisateurs.

Les RPM de cette  prochaine version de PHP 7.3, sont disponibles dans le dépôt remi pour Fedora 27, 28 et Enterprise Linux 6, 7 (RHEL, CentOS, ...) dans une nouvelle Software Collection (php73) permettant son installation en parallèle de la version système.

Traduction de l'article PHP Configuration Tips.

Cet article regroupe les informations actualisées qui ont été publiées ici au cours des dernières années.

Annonce : Red Hat updates Python, PHP, Node.js, more; supports new arches et RHSCL 3.0 Beta Release Notes.

Pas encore de version publiée, la version 7.2.0-dev est donc toujours en cours de développement, mais il me semble utile de commencer à la tester.

Les RPM de cette  prochaine version de PHP 7.2, sont disponibles dans le dépôt remi-test pour Fedora 24, 25, 26, 27 et Enterprise Linux 6, 7 (RHEL, CentOS, ...) dans une nouvelle Software Collection (php72) permettant son installation en parallèle de la version système.