It seems that the php-ioncube-loader package in the Atomic channel doesn't automatically add configuration to load the extension. The preinstall scriptlet removes any load statements from /etc/php.ini, but doesn't seem to add its own configuration file under /etc/php.d.

Ah, apparently this is handled via a trigger. However, this trigger only acts on the php package, not on the CentOS php53 package. Could a trigger be added for php53?

This is really a problem with the php53 package, not with the ioncube package. You need to report this bug upstream and let them deal with the fallout.

I don't see what upstream could do to fix this. The only solution I can think of is this one-line spec file change for the php-ioncube-loader package:



Can you think of another solution?

Why don't you ask them?

Because I think it's pointless. I guess I'll just have to exclude all Atomic PHP packages then.

I'm with Breun on this one. No way will they do anything, and it seems like a safe and sensible thing to add to the ART RPM?

I suspect we are missing/misunderstanding something.....

Im in agreement with all the other maintainers. There was no reason to fork those packages like this, we already had other channels to handle it (-extras, -contrib, etc).

I also agree that the php53* solution wasn't the greatest idea Red Hat ever had, but it's the long term supported stack for running PHP 5.3 on EL5, so that's what we install for clients explicitly requesting this.

I was hoping we could still use the Atomic php-ioncube-loader package in these setups, but if Atomic won't support the EL5 php53* way of things, then I guess we'll need to look for another solution for ionCube Loader for these clients.

Please note that I didn't mean to say that we're completely dropping support for Atomic PHP packages. Not at all, actually.