[CentOS-devel] SCL

[Johnny Hughes]

On 08/25/2014 10:40 AM, Pat Riehecky wrote:
> On 08/25/2014 10:03 AM, Les Mikesell wrote:
>> On Mon, Aug 25, 2014 at 8:25 AM, Johnny Hughes <johnny at centos.org> wrote:
>>>>> 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.
>>>>
>> Does anyone know if these will be updated for RHEL/CentOS/SL 7?
>> http://linux.web.cern.ch/linux/devtoolset/#dts21
>>
> 
> The official SL6 link is at:
> 
> http://ftp.scientificlinux.org/linux/scientific/6x/external_products/
> 
> And for SL7:
> http://ftp.scientificlinux.org/linux/scientific/7x/external_products/
> 
> Upstream has not published any EL7 packages for devtoolset.  So, right 
> now there really isn't anything to build.  Without promising anything, 
> SL is interested in this technology.
> 
> I've built up the EL7 SCL from 
> ftp://ftp.redhat.com/redhat/linux/enterprise/7Server/en/RHSCL/SRPMS/ but 
> it is not clear that these are officially released by upstream, so 
> they've not been published for SL7.

I would like to point out that if people want to use the Scientific
Linux version of SCLs, that is absolutely fine with me.  (Not that
anyone cares what I think :D )

The reason we are not publishing these is to try to an upstream process
set up where we can somewhat guarantee future updates, etc ... which is
what the CentOS team thinks is very important before we publish SCLs as
main CentOS distro repos.  (we don't want to start and not be able SCLs
to finish ... or ... we don't want to publish things that might be very
divergent from upstream unless it is a SIG).

Other groups might have a different requirement to publish SCLs (ie,
SL).  I am not saying any one way id right or wrong, etc.

Pat ... I would also like to invite you personally to participate in a
CentOS SCL SIG, if that is decided as the mechanism we use for this in
CentOS :)



-------------- 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/90d5c27f/attachment.sig>