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