CentOS 7/php56 dependencies
-
I need to install Kopano on a existing server with php 5.6 from the IUS repositories ( https://ius.io/ ). Very stable for years and regularly updated. Much preferred by me over the Software Collections solution in this case.
Been struggling last weeks with php-mapi having a different api version than php 5.6 but this seems ok on this installation, using the RHEL_7_PHP_56 repositories.The last dependency issue I’m running in to now is kopano-dagent being dependant on rh-php56-php from the Software Collections repo.
I wonder if it would be possible to have this changed to a dependancy like php being >=5.6 so Kopano can also be installed using a different php repo ?
Regards,
Paul -
I can of course use --skip-broken but would rather not do this and I’m not sure if it would work.
Paul
-
It’s basically about php-mapi extension
mapi.so.
yum xxx --skip-brokenwon’t help, but
rpm -Ivf --nodeps php-mapi-8.xxx.rpmprobably does what you expect.Anyway, you have to move
mapi.so/mapi.inito the correct (IUS) php-locations.php-mapi-*.rpm installs this to scl-based paths e.g. under /opt/rh/rh-php56/root (./lib64/modules and ./etc).
IMHO compiling Kopano from source is the better approach: You can hardcode your specific php-reincarnation during the configure-build-step
The smime-plugin (if used) also depends on a custom php-extension (kopano_smime.so) which can be found (src) here.
++umgfoin
-
@umgfoin said in CentOS 7/php56 dependencies:
IMHO compiling Kopano from source is the better approach: You can hardcode your specific php-reincarnation during the configure-build-step
Yes, that is probably the better approach when using a php version we not specifically deliver ourselves.
We actually hear complaints over the general scl architecture for red hat from now and then, but as of now this is the only way to go, if you still want to receive support from red hat.
-
