In RHEL 8 PHP is part of AppStream, so a module
My current plan:
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
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:
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."
Any progress here?
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?
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.
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.
I have filed issues with Koji and MBS about this:
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.
you mean MBS there... it's whats doing all the module builds.
I have filed issues with Koji and MBS about this: Koji: https://pagure.io/koji/issue/2483 MBS: https://pagure.io/fm-orchestrator/issue/1653
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.
So looks EPEL like is definitively a DEAD project.
No. It's an understaffed project, there's a difference. We're still waiting on MBS improvements. Have you considered asking the MBS folks if they can prioritize helping us?
EPEL is not dead. In fact, it was recently announced that the CPE team is going to staff EPEL work. This means that members of the CPE team will be able to work on EPEL tasks as part of their job, instead of in their spare time. This isn't a magic wand that makes the modularity problems go away, but it is great news for the future of EPEL.
Modularity is an immature technology that was rushed into RHEL long before it was ready. This is in no way the fault of EPEL. I personally told the modularity team back in 2017 that they needed to ensure compatibility between distro modules and third party modules (build requirements, additional streams, etc). That advice appears to have been unheeded. In the meantime, nothing is stopping you or anyone else from adding non-modular PHP packages to epel8 built against the default php:7.2 stream, which is enabled in the epel8 buildroot via grobisplitter.
Koji: https://pagure.io/koji/issue/2483 MBS: https://pagure.io/fm-orchestrator/issue/1653
The meta issue here is modules are not currently able to depend on modules built in a different build system, e.g. Fedora's MBS and RHEL's MBS. Those issues Neal opened with Koji and MBS upstream are the appropriate place to track the status of that. We don't need to duplicate that tracking, so I'm going to close this issue.
Metadata Update from @carlwgeorge: - Issue close_status updated to: Unable to Fix - Issue status updated to: Closed (was: Open)
In the meantime, nothing is stopping you or anyone else from adding non-modular PHP packages to epel8 built against the default php:7.2 stream, which is enabled in the epel8 buildroot via grobisplitter.
Sorry, but this does not make sense. php:7.2 is EOL and not maintained anymore php:7.4 is the stream version maintained for the whole distro life cycle.
In the meantime, nothing is stopping you or anyone else from adding non-modular PHP packages to epel8 built against the default php:7.2 stream, which is enabled in the epel8 buildroot via grobisplitter. Sorry, but this does not make sense. php:7.2 is EOL and not maintained anymore php:7.4 is the stream version maintained for the whole distro life cycle.
Then RHEL should switch the default from the EOL stream to the maintained one.
Open a ticket with CentOS Stream 8 to see if it can be done. Otherwise nothing that can be done in this ticket.
Even though this ticket is closed, I figure I should put a "minor" update in here: as of Koji 1.28, it became possible for Koji to configure modules for a buildroot per tag.
So now only MBS needs updating to handle it.
Login to comment on this ticket.