1. Goals

Like Fedora 29, RHEL-8 will use modules. The base distribution is reduced to a very minimal set of packages and libraries, and lot of applications / languages are now available via modules.

RHEL-8 provides php as a module, with 7.1 and 7.2 stream, and we can imagine more newer versions in the future.

All php extensions, which are dependent on the php ABI, will have to be part of the php module

All pure-php packages, applications or libraries, can stay in the base repository, as compatibility across version is usually good, we simply have to ensure compatibility with all streams.

For libraries, we already handles multiples versions, and switch to module scheme probably doesn't make sense: e.g.  we can need to install various applications requiring different versions of Symfony, which won't work if Symfony was only available as a module.

For some applications it can make sense to move them to dedicated module, e.g. glpi, owncloud and nextcloud seems good candidates

2. Modules and libraries

The preparation work is available in my repository for the remi-7.2 and remi-7.3 stream, and can be imported later to EPEL-8.

While I have not build yet all possible extensions (~70 for now) we obviously need some libraries not in base distribution, which make some questions raising.

2.1. Modules dependencies

To build PHP extensions I have to enable various modules providing some libraries or tools:

  • httpd:2.4: used at build (for mod_php) and runtime,
  • mariadb:10.3 used at build time for some test suites
  • nginx:1.14 used at runtime for php-fpm
  • nodejs:10 used at build time
  • postgresql:10 used at build time for some test suites
  • python27:2.7 used at build time
  • python36:3.6 used at build time
  • redis used at runtime for some test suites
  • sos-collector use at builtime and runtime for libsodium
  • swig used at buildtime
  • varnish:6 use at builtime and runtime for libvarnish
  • virt; used at build and runtime for libvirt

Some make sense (httpd, nginx, virt) but some are obviously bad and will raise issues, how can we imagine php module depending on sos-collector one ?

2.2. Possible solution

IMHO providing libraries in a module, and not being part of the provided module API is terrible, and should be avoid this can be fixed in various way:

  • shared libraries only in base system, using usual solution to provide multiple versions when needed (using soname in the package name, like I do for years in my repository, or in official repositories for compat packages)
  • in module, only static library, or hidden one (mangled soname + filtered provides and devel packages only available for the module)

Notice: all packages which will require libzip will have the same issue, as this library is for now only available in the php module.

Without proper Guildelines for libraries, EL-8 + EPEL will quickly become a terrible mess.

2.3. Others libraries

Some libraries, usually found in EPEL have been rebuild in my repository, temporarily, waiting for official EPEL-8 repository (ex: argon2, cmark, GeoIP, ImageMagick, ...)

3. PHP Framework, libraries and applications

The first step to be able to rebuild noarch packages for EL-8 is to have a quite huge set of tools, which includes some Framework (e.g. Symfony) and tools (e.g. phpunit).

As we have now a terribly complex bootstrap process, with tons of circular dependencies, I choose to use Fedora 29 noarch packages during the 1st build, and I hope it will be possible to do the same in real EPEL (tagging fc29.noarch RPMs in epel8-build).

This bootstrap step includes frameworks (symfony, ZF, ...) and developper tools (phpunit), and generates >400 noarch packages

Some packages (~20) have been fixed  in rawhide to properly manage EL-8 (range dependencies and proper conditions)

Everything else can be build only using el8 packages from previous step.

4. Current state

My repository is now populated with >500 packages which includes

  • Extensions
    • Nearly all
  • Frameworks
    • Symfony v2, v3 and v4
    • Zend Framework
    • Sabre
    • Doctrine
  • Developer's tools
    • atoum
    • composer
    • phan
    • phpcompatinfo
    • php-cs-fixer
    • PHPUnit v5, v6 and v7
  • Web applications
    • GLPI
    • phpMyAdmin
    • roundcubemail
    • wordpress

More will come soon.

5. Conclusion

The main work is done, and most of my packages are ready in rawhide, and testable using my repository, just waiting for EPEL-8 to exists.