[CentOS-devel] SCL

Mon Jul 21 22:04:56 UTC 2014
vincent at vanderkussen.org <vincent at vanderkussen.org>

On 2014-07-21 22:27, Peter Meier wrote:
> Hash: SHA1
>>> 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.
> Johnny, thanks a lot for your extensive summary of the problems you ran
> into and the possible ways out.
>> 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.
> I totally understand your concerns and agree with your conclusion.

Indeed. Not an ideal situation to build packages from. I also agree with
the above. Thanks Johnny for pointing that out.
>> 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.
> Right, I also think that having a SIG for that would be the best option
> and actually if SL already did the hard work, it would be nice if a
> collaboration could happen.
> SCLs are really something of the most innovative things that came out
> within the EL-ecosystem in the past few years and which has the
> potential to make the platform really more interesting for developers
> and others that have "more modern" requirements than the latest major 
> EL
> release.
> Hence, it would be a pitty if the CentOS platform wouldn't support it 
> in
> some way.
> I'm not writing that to say that *you* should do something about that,
> more to just share my opinion.
> I'm not sure if I could be part of such a SIG, but would certainly
> welcome such an initiative and try to support it in some way...

Although (imho) a SIG would probably be the best way to handle
this, Isn't this going to lead to a lot of separate repositories/sources
that you need to get stuff installed? Especially with all the other SIGs
that are getting form. This might also lead to conflicts between all the
SIGs repos. In the case of SCL, in c6 this was included in the standard

On the other hand, a SIG that takes care of bringing more recent 
of packages (like SCL does) in CentOS does make sense because now people
try to rebuild recent versions themselves or add 3th party repos which
brings other problems.


> ~pete
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> d be
> ZzgAn0PYKzchx/jVQdENrANghe6Yx/9V
> =JWZo
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> http://lists.centos.org/mailman/listinfo/centos-devel