[CentOS-devel] SCL

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.sig>