Hi,
I was wondering if SoftwareCollections was already available in CentOS7?
Regards, Vincent
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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.
Thx!
~pete
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/softwar...
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
Thanks, Johnny Hughes
-----BEGIN PGP SIGNED MESSAGE----- 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/softwar...
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.
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...
~pete
On 2014-07-21 22:27, Peter Meier wrote:
-----BEGIN PGP SIGNED MESSAGE----- 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/softwar...
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 repository.
On the other hand, a SIG that takes care of bringing more recent versions 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.
Vincent
~pete -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ d be iEYEARECAAYFAlPNd64ACgkQbwltcAfKi3+aMACgnxMlxHDGMJyCwNVGbRPHTNs7 ZzgAn0PYKzchx/jVQdENrANghe6Yx/9V =JWZo -----END PGP SIGNATURE----- _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 07/21/2014 03:27 PM, Peter Meier wrote:
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.
I'll also toss a quick plug in for my personal favourite use of SCLs - legacy software.
The ability to add more modern software in parallel is nice, but I often find I've got a lot of legacy code that needs to hang around for longer than I'd like. Shoving this older (often well past EOL) software in a corner where I don't have to touch it is strangely comforting.
"Oh, your application requires this strange bug from OpenLDAP 2.1, ok I'll put that over here listening on localhost and you can deal with making your stuff talk to it" "You mean your software doesn't work with MySQL 5.1, ok here is a 5.0 server listening on localhost you can use" Then simply add stunnel with client validation and you're all set.
There is a lot more upfront work, but migrating legacy apps has always been a real pain for me. I see the SCL technology as perhaps the greatest step forward on this front in a long time. This weird app requires these packages, fine here is a self-contained environment with all your stuff and I'll never touch it while fixing other issues. Docker may also be a benefit for this use case as well, but SCLs don't make "one more thing to manage".
Pat
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/softwar...
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
On Mon, Aug 25, 2014 at 8:25 AM, Johnny Hughes johnny@centos.org wrote:
Scientific Linux has produced these SCLs here:
http://ftp.scientificlinux.org/linux/scientific/6x/external_products/softwar...
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
On 08/25/2014 10:03 AM, Les Mikesell wrote:
On Mon, Aug 25, 2014 at 8:25 AM, Johnny Hughes johnny@centos.org wrote:
Scientific Linux has produced these SCLs here:
http://ftp.scientificlinux.org/linux/scientific/6x/external_products/softwar...
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.
Pat
On Mon, Aug 25, 2014 at 10:40 AM, Pat Riehecky riehecky@fnal.gov wrote:
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.
Thanks - I was hoping someone would make a packaged eclicpse/luna and groovy 2.x with whatever library support they are likely to need.
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@centos.org wrote:
Scientific Linux has produced these SCLs here:
http://ftp.scientificlinux.org/linux/scientific/6x/external_products/softwar...
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 :)
-
Johnny Hughes -
Les Mikesell -
Manuel Wolfshant -
Pat Riehecky -
Peter Meier -
vincent＠vanderkussen.org