Work in progress: PHP stack for EL-8
+
Par Remi le mardi 11 décembre 2018, 11:23 - Développement - Lien permanent
As RHEL-8.0-Beta is released, it's time to start preparing PHP stack for EPEL-8.
Here some notes about this work in progress.
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.
Commentaires
Good job. I'm still looking in the app stream/modules idea. For using it sounds great, but building them is a lot more complicated it seems.
Question: Will the php72 and php73 packages remain or will they demise like the SCL on RHEL8?
> Will the php72 and php73 packages remain
Not build yet, but I plan to build some SCLs for EL-8 soon, as I think multi-versions is really a useful feature.
Only need time ;)
Re the section "2. Modules and libraries", I have been warning about these issues from day one, ever since Modularity was discussed in Fedora. I think this is a fundamental failure of the concept of modules. Unfortunately, my objections were totally ignored, Fedora (and now RHEL) went ahead with the Modularity plans anyway, despite having no solution to the problems I brought up. Now you rediscovered them.
It was clear to me even before even a single module was packaged that exactly the problems you are running into would happen:
* a module such as PHP having to require several other modules. This also means you have to depend on a specific version of them, leaving users who need other versions of the dependencies in the cold. This concept of "mix and match arbitrary versions of each module" just does not work in practice where there are dependencies.
* libraries that you need hidden inside an unrelated module such as sos-collector. This is particularly unhelpful, especially because you need to prevent conflicts between modules that happen to bundle the same library. Yet, you are also not supposed to depend on the other module for that library if it is not part of its API. It just does not make sense to put libraries such as libsodium or libzip into some larger module.
Unfortunately, the developers of Modularity either did not foresee the issues or did not care. Either way, they still did not care when I pointed out those issues to them.