On 07/20/2014 01:55 PM, Johnny Hughes wrote: > On 07/20/2014 01:30 PM, Peter Meier wrote: >>> I was wondering if SoftwareCollections was already available in >>> CentOS7? >> >> Also interesting to know what the plans for SCL 1.1 for C6 are? I >> assumed that development there are/were hold back because of C7, but >> given that they bring some significant improvements, it would be nice >> if they are going to be released soon. > > I am trying to build them, however I am running into issues as not > everything needed to build them is part of SCL for RHEL .. for example: > > https://bugzilla.redhat.com/show_bug.cgi?id=1105230#c3 > > So, the issue is that there are build requires missing from several of > the packages, so decisions need to be made how and where to create these > new build requires and how they need to be maintained, etc. > > I can find, via softwarecollections.org, packages to build the packages > in RHEL 1.1 SCLs now ... however, I am not at all sure that those > additional 'Build Require' packages will be maintained for security > updates in the future, etc. Since there is clearly no ability to use > 'officially' maintained code to be able to produce these packages, I am > reluctant to officially produce them for CentOS at this time. (see the > above linked comment, I don't think the 'Build Require' packages which > are not actually part of the RHEL SCLs are going to be released) > > Scientific Linux has produced these SCLs here: > > http://ftp.scientificlinux.org/linux/scientific/6x/external_products/softwarecollections/ > > Since I am personally uncomfortable putting the CentOS name on SCLs that > I can not verify are the same as upstream because the repo is not self > hosting (ie, they are not saying what they are building against and not > providing or publicly auditing these 'Build Require' packages for > security, etc), I am not planning on officially releasing these > anymore. We can, as a SIG, decide to produce and maintain secure all > the 'Build Require' packages but that is going to require people willing > to figure out AND maintain those packages that are needed. In the > meantime, I recommend you use the packages produced by Scientific Linux > if you want to use SCLs that are known as RHEL 1.1 for EL6. > > Note: there are several Maven, Java, and other packages required to > build out the entirety of that tree and not having any idea of the exact > packages required means to me that we can not produce a 'rebuild of > upstream sources' in the way that CentOS provides official packages and > why I think these should instead be part of a SIG Here is a status update on this issue: 1. CentOS can not and will not publish things as an official rebuild repo if we can not build things that have all the build requires provided upstream. It is clear that all those things are not going to be provided by this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1105230 2. There have been talks to make softwarecollections.org the canonical upstream for Software Collections. That is currently NOT the case, as evidenced by the differences between the following: ======================================== mongodb24: http://copr-be.cloud.fedoraproject.org/results/rhscl/mongodb24/epel-6-x86_64/ ftp://ftp.redhat.com/redhat/linux/enterprise/6Server/en/RHSCL/SRPMS/ The above links show this: SCL.org build: javapackages-tools-3.4.1-1.1.el6.src.rpm mongodb24-1.1-3.el6.src.rpm mongodb24-gperftools-2.0-18.el6.src.rpm mongodb24-gtest-1.6.0-3.el6.src.rpm mongodb24-gyp-0.1-0.11.1617svn.el6.src.rpm mongodb24-libunwind-1.1-4.el6.src.rpm mongodb24-mongo-java-driver-2.11.4-1.el6.src.rpm mongodb24-mongodb-2.4.9-4.el6.src.rpm mongodb24-scons-2.3.0-2.el6.src.rpm mongodb24-snappy-1.1.0-6.el6.src.rpm mongodb24-v8-3.14.5.10-2.3.el6.src.rpm RHEL 1.1 SCLs: mongodb24-1.1-5.el6.src.rpm mongodb24-gperftools-2.0-18.el6.src.rpm mongodb24-libunwind-1.1-4.el6.src.rpm mongodb24-mongo-java-driver-2.11.4-2.el6.src.rpm mongodb24-mongodb-2.4.9-8.el6.src.rpm mongodb24-snappy-1.1.0-6.el6.src.rpm As you can see ... the softwarecollections.org build is not canonical .. it is far behind in several ways. Notably: 1. Older versions of mongodb24, mongodb24-mongo-java-driver, mongodb24-mongodb. 2. The SPEC files differ greatly for the build process in that mongo24-mongodb in RHEL version builds against the v8 in the repo while scl.org version has a special version for mongodb24 ... same for gyp. 3. There are other extra packages in the SCL.org version that do not appear in the RHEL version. These are the things that make it self hosting. Things like javapackages-tools, mongodb24-scons. The issue with the SCL.org versions are this: a. We have no idea if they are in any way audited for security or updated. b. We have no idea if they OR something completely different is the upstream build root for RHEL SCLs. This is just one package ... there are many others (themostat, nginx, httpd, etc). ==================================== For the above reasons, the CentOS Project can not build what is currently released in either location and call it a rebuild of the upstream source code because: 1. RHEL SCL source code is not self hosting. 2. SCL.org source code is not maintained in a timely manner for Security or Bugfix updates. 3. There are things in SCL.org source code that is not in RHEL SCL source code and there is assurance of any kind that those additive items are in any way maintained for security, etc. =================================== 1. So what does this mean for SCLs in CentOS? It means that the team is not going to build either the items in SCL.org or RHEL sources as they currently stand. 2. What does this mean for the SCL items already released in CentOS-6.x The 10 packages that were initially released in RHEL version 1.0 SCLs and also released in CentOS-6.x tree are still self hosing and we will continue to publish update specifically for those 10 packages as long as they are self hosting. Those can be found here: http://mirror.centos.org/centos/6.5/SCL/x86_64/ Since these have already been released, we will maintain them as long as we can, audit them for security and put maximum effort into keeping them updated. 3. What does it mean for other items being added into CentOS-6.x from RHEL 1.1 SCL release or CentOS-7.x SCLs. Until such time as there is a canonical update stream that provides audibility and closure ... OR ... there is enough external (to the CentOS Project) volunteers for a an SCL Special Interest Group, we will not be adding any more SCLs officially to CentOS, either new things to CentOS-6 or any to CentOS-7. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20140825/502fdfdb/attachment-0006.sig>