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)

I just moved all my web sites to a new server.

If you read this entry, this means DNS have done their work, and you are connected to this new server.

See the PHP supported versions list.

So, now, some noarch packages in the remi repository require 7.2 as the minimal required version.

foo requires php(language) >= 7.2

Shortly after RHEL-8, CentOS 8 is released and of course my repository is already open and fully populated.

After PHP 7.0, and as announced, PHP version 5.6.40 was the last official release of PHP 5.6

Which means that after version 7.2.15 and 7.3.2 releases, some security vulnerabilities are not, and won't be, fixed by the PHP project.

To keep a secure installation, the upgrade to a maintained version is strongly recommended:

• PHP 7.2 is in active support mode, and will be maintained until December 2019 (2020 for security).
• PHP 7.3 is in active support mode, and will be maintained until December 2020 (2021 for security).

Read :

• PHP Supported versions
• Migration guide from PHP 5.6.x to PHP 7.0.x
• Migration guide from PHP 7.0.x to PHP 7.1.x
• Migration guide from PHP 7.1.x to PHP 7.2.x
• Migration guide from PHP 7.2.x to PHP 7.3.x

However, given the very important number of downloads by the users of my repository (>30%)  the version is still available in  remi repository for Enterprise Linux (RHEL, CentOS...) and Fedora (Software Collections) and will include the latest security fix.

Warning : this is a best effort action, depending of my spare time, without any warranty, only to give users more time to migrate. This can only be temporary, and upgrade must be the priority.

Fedora 29, and soon RHEL / CentOS 8, can use "modules", which works like additional repositories, providing alternative versions of software.

Read: Introducing Application Streams in RHEL 8

My repository now supports this feature (and also the old way).

For some years, the package development tracking for my repository was managed on a github repository: https://github.com/remicollet/remirepo.

This was, of course, for easiness.

Contrary to fashion of using this gratis, but not really free, service, I chose to self-host my work on the dedicated server already used for my repository, my blog and the forum.

All the sources of packages, tools and web sites will be progressively moved to the git.remirepo.net server, and can be browsed on  https://git.remirepo.net/cgit.

Github repository will stay open, only used for issues and other requests, but patch proposal should be send by email (preferably using  git format-patch so I can apply them using git am).

I will also consider moving from cgit to pagure, as soon as possible.

After PHP 5.4, and as announced, PHP version 5.5.38 was the last official release of PHP 5.5

Which means that since version 5.6.25 and version 7.0.10 have been released, some security vulnerabilities are not, and won't be, fixed by the PHP project.

To keep a secure installation, the upgrade to a maintained version is strongly recommended:

• PHP 5.6 is in active support mode, and will be maintained until December 2018.
• PHP 7.0 is in active support mode, and will be maintained until December 2018.
• PHP 7.1 is in under development, in stabilization phase (Release Candidate) and should be released as stable quite soon.

Read :

• PHP Supported versions
• Migration guide from PHP 5.5.x to PHP 5.6.x
• Migration guide from PHP 5.6.x to PHP 7.0.x
• Migration guide from PHP 7.0.x to PHP 7.1.x

However, given the very important number of downloads by the users of my repository (~20%)  the version is still available in  remi repository for Enterprise Linux (RHEL, CentOS...) and Fedora (Software Collections) and includes the latest security fix.

Warning : this is a best effort action, depending of my spare time, without any warranty, only to give users more time to migrate. This can only be temporary, and upgrade must be the priority.

Version 5.5.38-2 includes fix backported from 5.6.25.

Base packages (php)

Software Collections (php55)

The remi repository will be soon 11 years old, and we just reached the 100 millions of downloads :)

Of course, this is only an indicator, first years are not included, some people aspire the full repository, and lot of private mirrors are used and are not included in this figure, but it allows me to observe the growing success of my work, and to compare the popularity of the various available packages.

If the received donations finance the hosting, they are mostly a proof of the usefulness of my work and of the users gratefulness. When they will stop, I will know I can close the site.

Some other repositories try to come after, pulling my work, here or in fedora. They will always stay behind.

A small regret : PHP 5.4 still represent 34% of the downloads, too much (PHP 5.5 20%, PHP 5.6 40% and PHP 7.0 7%) but tendency is good, just a bit slow for me.

A satisfaction : Software Collections represent around 20%, which is a proof this is a good tool, matching a real need of parallel installation.

Small notice: I also need your testimonials.

The "remi" repository exists for > 10 years, it have changed a lot, and some recent changes worth to be explained.