On 11/26/2014 07:51 AM, Remi Collet wrote:
Le 25/11/2014 09:05, Honza Horak a écrit :
Hi guys,
Hi,
this is a draft for CentOS dist-git design I put together from various notes/ideas. It still needs to polish, so it will probably be changing in but I wanted to share it as soon as possible to gather feedback soon and incorporate your ideas.
https://fedoraproject.org/wiki/User:Hhorak/Draft/centos-scl-git-proposal
First, sorry for stupid questions, but it seems I still haven't understand the goal, what we want to fix, and how.
Remi, thanks for them! For some I had no answer yet, so I added them to the wiki with some just figured out answer: https://fedoraproject.org/wiki/User:Hhorak/Draft/centos-scl-git-proposal#FAQ
Also CC'ing centos-devel list, since these are all questions we need to answer publicly.
So, what we want to fix here.. CentOS is a platform used by huge amount of users, who e.g. develop apps for RHEL. Missing SCLs in CentOS is then problem for those users, because they cannot develop apps using SCLs. I guess there are no doubts SCLs are needed in CentOS.
Then, why move *development of the future SCLs* to CentOS and not rebuild RHSCL there downstream? There are RH projects (like OpenShift) that also need to have community version of the product available publicly for all, so they started to use CentOS as their development platform. That means fixes land in git.centos.org first, where everybody can test, and community can see code that will land in RH in the future. So they build community on CentOS.
Given there are already projects using CentOS as development platform and given users use CentOS as development platform, we see it as great opportunity to build community around SCLs there as well, which is what SCLs is missing.
Also, it makes sense to have a common platform where upstream development of RH layered products takes place and where products may interact. We consider CentOS to be this platform now.
"... where future upstream development of Software Collections will take place"
So, if I understand correctly, if I want to create a "php56" collection, I should be able to do it in git.centos.org ?
Yes.
Where the packages will go (which repository) ?
My proposal is to use one repository on CentOS side for all collections. However, this will be a different repository than the one for rebuilt RHSCL collections (if there ever will be such a repository).
How user will see the difference between "stable" packages and "development" packages ?
I'm not sure yet, but there can be two repositories. One repository with stable downstream rebuild of RHSCL, another with SCLs that include fixes above RHSCL and have quality compared to Fedora.
If, at some time, RH provides a "php56" collection, this can be pulled from this one. But what will happen next to earlier packages ?
Nothing, it will stay, new patches will still be landing there before they land in RHSCL.
Will the ACL on the package stay the same ?
ACLs were not consulted yet.
About koji setup:
Which repository/tags will be enabled in each target ?
I expect only CentOS and already built SCLs will be available.
Especially, will EPEL be available, or some replacement ?
I don't think so, why EPEL?
Will the SCL-SIG be able to add additional packages in existing collections ?
If you mean already released collections, we haven't consulted what will happen with them, just that sources are already available for CentOS and we'll let CentOS community to build them. For new collections, which are subject of this proposal, it will be possible.
Exemple : for now, Fedora is upstream for RHEL, packages are then split between RHEL and EPEL (short way to describe what happen).
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.
From my point of view, there should be a clear definition of "upstream"
Old: "Fedora is upstream of RHEL" New: git.centos.org is upstream of RHSCL, in one "experimental" repository (not yet in RHSCL)
Yes.
Old: "RHEL is upstream of CentOS" New: git.centos.org receive clone copy of RH content in one "production" repository. (clone of RHSCL)
git.centos.org produce more content in one "additional" repository (like EPEL for RHEL)
Yeah, the whole point is that CentOS won't be only downstream for all RH products any longer. It will stay downstream for RHEL, but upstream for some other projects.
I think we probably even need more git or more branches, not a single one)
Git will be similar to what we have internally, one repository per component and branch for every "combination of CentOS and collection" where it makes sense. But it is already mentioned in the proposal.
Regards, Remi.
P.S. are we trying to kill Fedora ?
I hope not :) Just SCLs don't bring so much value for Fedora users, since they already have their packages in latest versions there. That does not mean SCLs are not usable there, I'd love to see SCLs in Fedora still; just we focus more on CentOS now because it will solve more issues for more users currently.
Honza
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...).
Remi.
[1] list on http://rpms.famillecollet.com/rpmphp/rpm.php?type=pecl
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
-
Honza Horak -
Remi Collet