[CentOS-devel] [rh-scl] Proposal for CentOS dist-git design

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