#75 [EPEL-8] PHP stack
Opened a year ago by remi. Modified 16 days ago

In RHEL 8 PHP is part of AppStream, so a module

  • php:7.2 in 8.0
  • php:7.2 and php:7.3 in 8.1

My current plan:

  • build C extensions which depends of php version, i.e. on php(api) and php(zend-abi) as module
  • (later) build some noarch packages

Questions: how to do this ?

  • add additional packages in the *php stream (in theory, we can have various repo with packages in the same stream, ex: base + updates), but IIRC I was told this in not the proper way, stream definition is unique and in RHEL (package list / profiles / default)

  • create a new "php-extras" module, with stream matching "php" one.

Are the builder ready for this ?

How should I request new module / stream / branch creation ?


@sgallagh will need to look at this.

Also about the branch names

  • module/php-extras => 7.2 ?
  • rpms/php-extras => stream-el8-7.2 ?
  • rpms/php-pecl-amqp => stream-el8-7.2 ? 1.9 ?

yeah, currently we have no way to build modules for epel8. This is being worked on now to hopefully land with 8.1.

Requests for additional packages start to pile up (bugs 1750404, 1753681, 1753683, 1753693, 1753712, 1755408, 1755653, 1755654, 1755655...) and are linked to this issue, I think it is nice to have a temporary workaround

So if you need addition PHP extensions, lilbraries or applications, see
https://blog.remirepo.net/post/2019/09/24/CentOS-8-repository

Additional question about dependencies in epel-playground

Ex: tidy, GeoIP, ...

Do we need 2 modular repositories ?

Examples:

  • php-imap depends on uw-imap in epel
  • php-tidy depends on libtidy in epel-playground

I built both of those for KDE. They are in -playground because KDE is in playground. I am not the regular Fedora/EPEL maintainer for either of them, so if someone wants to open a bugzilla and get them put into plain EPEL8, I'm totally fine with it.

Just so you know, the Fedora maintainer of GeoIP contacted me and let me know that he's planning on phasing it out and retiring it, due to the data being so old for it.

This is what he said.

"I personally think it would be better to build applications without GeoIP support rather than giving the (false) impression that it's a supported thing, particularly at the start of EPEL-8's lifetime.

Upstream would clearly prefer that everyone migrated to libmaxminddb but uptake appear to be very slow."

Modules in epel8 progress:
It has progressed nicely. We are currently testing in stage. modules build. bodhi does their update. The final step, where the modules go into a "compose" (such an overloaded word) so that users can see the module with normal dnf commands, is being worked on.

tidy: (from a couple comments up)
tidy is now in regular epel. No need for a module.

CentOS 8.1 is available. Any update on this issue?

modules are now available to build. What do we need to give so you can start producing them?

modules are now available to build. What do we need to give so you can start producing them?

  • module name ?
    • php-extras with dependency on php, but not user friendly
    • php (only additional package for upstream php streams)
  • way to requests branch

When extensions (binary) will be ready, if possible to create a side tag, will all rawhide php noarch packages tagged, to avoid having to bootstrap 500 packages with tons of circular dependencies (at least to build minimal stack with autoloader and phpunit, used by nearly everything else)

FYI:

https://pagure.io/fedora-infrastructure/issue/8690
Can't build module with dependency on module in RHEL

https://pagure.io/fedora-infrastructure/issue/8687
module: bad constraint branch = stream

As it seems it will take some more time before anything happen in EPEL

First workaround:

Use remi repository, which provides PHP 7.2, 7.3, 7.4 modules, with nearly all possible extensions, and also lot of "noarch" packages.

Second workaround:

Use test build from spec file ready for EPEL-8, Download test packages from

See the repository configuration file: epel-temp.repo

Feel free to ask for missing packages.

Nearly 2 years after 8.0-Beta, and 1 year since his ticket is open, I think it is time to declare EPEL-8 as a dead / broken project.

EL-8 is a modular distro, not being able to provide modular packages is terrible, and doesn't match user needs.

And some people start building against the default stream for some packages, this sounds such a bad idea (making other streams unusable)

This will become worst in the next years (with some streams reaching their EOL)

@remi Thank you for trying.

Actually we migrated a couple of servers from RHEL 7 to Fedora (instead of RHEL 8) because of the current state of PHP in EPEL 8. Turns out Fedora is working great for us.

Nearly 2 years after 8.0-Beta, and 1 year since his ticket is open, I think it is time to declare EPEL-8 as a dead / broken project.

I'm sorry you think so. I think it's very useful to many people, sorry it's not been able to live up to your modular needs.

I can only see 2 ways to improve things here:

a) Perhaps you could investigate becoming a CentOS sig? I am not sure if they can build modules, but if so, CentOS should have all the modules available and avoid the issues that EPEL has.

b) We need someone who knows modules very well to build us some kind of 'module import' tool. We could then import the centos modules and build against them. This would need to update koji, mbs, all the tags, etc.
We can ask the new mbs owners if they would be willing to take this on.

We don't need a module import tool, we just need some minimal awareness by Koji of how to set up module environments when all the modular repos are external. This became possible to do merely a month or so ago with Mock 2.4 release, so we just need to plumb that through to Koji.

This became possible to do merely a month or so ago with Mock 2.4 release,

Not true.
I'm building locally module aware packages since 8.0beta in Nov 2018 !

config_opts['module_enable'] = [ "php:7.3", ...]

Nearly 2 years after 8.0-Beta, and 1 year since his ticket is open, I think it is time to declare EPEL-8 as a dead / broken project.

I'm sorry you think so. I think it's very useful to many people, sorry it's not been able to live up to your modular needs.

It is not "my" need. I just close >20 bugs asking for PHP packages in EPEL-8 as "CANTFIX".

a) Perhaps you could investigate becoming a CentOS sig?

EPEL-7 is already broken for same reason, being unable to provide SCL packages, and as I have a lot of requests for PHP extensions, I have worked with "CentOS Sclo SIG" to build them there ("sclo-php" packages extending "rh-php" SCL)

It is a poor workaround and a high signal of failure for Fedora/EPEL project.

For EPEL-8, as a workaround, I quickly setup a local build env and provide missing extensions there for months.

The Fedora community has killed SCL. The Fedora community is killing modularity, victims are our users, who only need some ext to have a usable distro.

This became possible to do merely a month or so ago with Mock 2.4 release,

Not true.
I'm building locally module aware packages since 8.0beta in Nov 2018 !

config_opts['module_enable'] = [ "php:7.3", ...]

Yes, but overriding enabled modules (from cached chroots) or disabling default modules was impossible prior to this new option.

We don't need a module import tool, we just need some minimal awareness by Koji of how to set up module environments when all the modular repos are external. This became possible to do merely a month or so ago with Mock 2.4 release, so we just need to plumb that through to Koji.

you mean MBS there... it's whats doing all the module builds.

I have filed issues with Koji and MBS about this:

Sure, if MBS can be made aware of/use external repos for modules that would solve it as well. My understanding is that there is not enough information there, but I could be wrong. Currently it knows what packages are in all modules so it can tag builds into the buildroots/targets it makes to build modules.

Also external repos for modules wouldn't solve the 'build only/filtered out' packages issue. If the module was imported it could use those build only things, if it was pulling from a external repo it would not have access to them, which would break a lot of builds.

Anyhow, I guess we will see what MBS developers say.

Login to comment on this ticket.

Metadata