Additional PHP packages in EPEL-9

[Remi Collet]

Hi,

If you miss the news

RHEL 9 Beta is released
CentOS Stream 9 is available

This new major version provides PHP 8.0 in AppStream
but not as module.

This version will be maintained for the whole distribution
life cycle (8.0.12 for now)

Additional versions can be expected later as modules

So we can build additional package in EPEL-9
but only for PHP 8.0 (this is fine today, but
will become a problem in the future if we
still can't build for modules in EPEL, like for 8)

My plan:

I choose to concentrate myself on C extensions

A first set are already available in testing:
ast, http, sodium, memcache, mongodb, msgpack, raphf,
redis, rpminfo, uuid, yaml

Another set will come soon:
uopz, ssh2, xattr, amqp, zstd, pcov, psr, mailparse,
apfd, json_post

Some other are waiting for needed dependencies:
gearman, lzf...

I don't plan to maintain any PHP library there
only a minimal set, when requested, and if they
don't require a big bootstrap work.

For now, only php-fedora-autoloader and its dependencies
are already available.

WARNING: no phpunit
(so you have to disable test suite for EL build)

I also plan to provide a few set of applications
(roundcubemail, phpMyAdmin, wordpress...)
but using all libraries bundled.

If someone is crazy enough to help and take care of
more packages, he is very welcome.

FYI, the minimal stack for available applications,
their dependencies, and developer tools needed to
build them is around 500 packages, with a lot of
circle dependencies.

Cheers,
Remi

[François Kooman]

On 07.12.21 07:41, Remi Collet wrote:
> Hi,

Hi Remi,
> A first set are already available in testing:
> ast, http, sodium, memcache, mongodb, msgpack, raphf,
> redis, rpminfo, uuid, yaml

I've been testing with them and it works great with my software! Thanks!
> For now, only php-fedora-autoloader and its dependencies
> are already available.
>
> WARNING: no phpunit
> (so you have to disable test suite for EL build)

As part of working on some simpler software, I've been playing with 
writing my own autoloader [1] (still needs tests and proper project) and 
drop-in PHPUnit [2] minimalist replacement without dependencies and only 
a few features. So far they do work for the most part for simple scenarios.

I'm not sure how to best deal with the increased complexity of "modern" 
software, except fight it and keep things as simple as possible. It 
might be unsustainable in the long run, but at least for now it more or 
less works and I can deploy and test/build on EL without requiring any 
packaged 3rd party PHP libraries. Not sure if this approach is something 
I should pursue...

Thanks for your work on PHP in Fedora/EL!

Regards,
François

[1] https://gist.github.com/fkooman/af92e8bb7beb9fcb7ba4bb481a8fb969
[2] https://git.sr.ht/~fkooman/put, https://git.sr.ht/~fkooman/put.rpm

[Remi Collet]

Le 08/12/2021 à 13:20, François Kooman a écrit :
> I'm not sure how to best deal with the increased complexity of "modern" 
> software, except fight it and keep things as simple as possible. It 
> might be unsustainable in the long run, but at least for now it more or 
> less works and I can deploy and test/build on EL without requiring any 
> packaged 3rd party PHP libraries. Not sure if this approach is something 
> I should pursue...

For memory, main issues for me

1/ number of packages vs number of packagers

I don't want to maintain more libraries
Already own too much without real help

2/ time waiting for package reviews

roundcubemail 1.5 was blocked for weeks because
of lack of roundcube/rtf-html-php [1]

composer 2.2 will probably be blocked because
of lack of composer/pcre [2]

3/ Exception to package review

From Review Guidelines [3]

> Contributors and reviewers MUST follow the Package Review Process,
     > with the following exceptions:
     > ...
     > * The package is being created so that multiple versions
     >   of the same package can coexist in the distribution.

but this only apply for a "compat" package (old version)
not for a newer version, which is for now the common practice
for PHP libraries. I have tons of such packages, and I'm too
tired to submit them to review (and see §1) and don't want
having to change our common practice.

4/ Symfony

This is the most commonly used set of libraries,
but also the one for which we are unable to run tests.

Version 5 is released for a while, 6 is coming,
but we still only have 4.

Some updates are already blocked by Symfony 5
(laminas/cli, laminas/cache, php-cs-fixer...)

5/ Phar

is the new way to distribute CLI application
perhaps simple to use them in RPM
(single file in /usr/bin)

=> phpnuit, composer, phpcompatinfo, php-cs-fixer...

Remi

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2015452
[2] https://bugzilla.redhat.com/show_bug.cgi?id=2030376
[3] 
https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#...

[François Kooman]

On 08.12.21 17:14, Remi Collet wrote:
> Le 08/12/2021 à 13:20, François Kooman a écrit :

Hi Remi,
> composer 2.2 will probably be blocked because of lack of
> composer/pcre [2]

Reviewed!

If you have any others that are critical for the 'basic' tools let me know.

Regards,
François

[Remi Collet]

Hi,

Le 10/12/2021 à 10:19, François Kooman a écrit :
> On 08.12.21 17:14, Remi Collet wrote:
> > Le 08/12/2021 à 13:20, François Kooman a écrit :
>
> Hi Remi,
> > composer 2.2 will probably be blocked because of lack of
> > composer/pcre [2]
>
> Reviewed!

Thanks!
> If you have any others that are critical for the 'basic' tools let me know.

I used to maintain a list on my blog
    https://blog.remirepo.net/pages/Pending-reviews

For now, only php-zumba-json-serializer is a blocker,
used at build time for some phpMyAdmin dependency.

Cheers,
Remi
> Regards,
> François
> _______________________________________________
> php-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/[e-mail]....
>
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure