On 11/27/2014 07:56 AM, Remi Collet wrote:
Le 26/11/2014 18:34, Honza Horak a écrit :
How can we manage, p.e. php-mcrypt (huge user demand) in this configuration ? (part of php in Fedora, and php-extras in EPEL).
Not sure what are you asking for. php-mcrypt will be part of php56 collection for instance, but I probably did not understand the question.
php-mcrypt is only an example, not part of php54 or php55 (or any other future collection). This extension have a dependency on libmcrypt not in RHEL/CentOS.
For base packages, this extension (and its dependency) is available in EPEL.
For SCL, we have
https://www.softwarecollections.org/en/scls/rhscl/php54/ clone/backport of official RHSCL
https://www.softwarecollections.org/en/scls/remi/php54more/ additional packages (initially designed for EPEL, but ...)
And of course "mcrypt" is only an example. php-extras provides: interbase dependency on firebird mcrypt dependency on libmcrypt mssql dependency on freetds imap dependency on libc-client tidy dependency on libtidy
And of course Fedora/EPEL have tons of extensions [1] which are not available in RHEL nor RHSCL.
Some are useful for modern web (mongo, redis, zmq...) some for developers (xhprof, xdebug...).
This is an interesting topic and to be honest I don't have an answer right now. It also depends what happens with collections available on softwarecollections.org -- it won't make sense to build the same packages again for that portal as soon as we have them available in CentOS.
Instead, what makes much better sense to me would be using SCLs from CentOS available in copr and build only the additional packages as you do for https://www.softwarecollections.org/en/scls/remi/php54more/ (won't need any changes in copr, since it accepts any repository as base, right?).
So, in other words -- I'd let SCLs in CentOS to be just the base platform (content similar to RHSCL) and provide any additional packages using copr on softwarecollections.org.
Does it make sense this way?
However, in order to do one step at a time to not to get stuck, I think we will focus on SCLs built strictly on top of RHEL content for now.
Honza