Description of problem: The version of Python 2.7 in SCL is several bugfix releases behind Version-Release number of selected component (if applicable): 2.7.5 Additional info: I poked around trying to find a statement on the actual update policy for software collections and didn't find one. I know that RH is doing support cycles for the official ones, and they just announced SCL 2.0, but I didn't see anything about the actual built version of the software in this repository (or other existing collections.
RHSCL 2.0 will have Python 2.7.8. It is likely that in future version of RHSCL there will be an SCL with Python 2.7.9, but I can't guarantee that. The updated python27 SCL with Python 2.7.8 will eventually make it to sofwarecollections.org. Is this sufficient for you? Thanks.
For the most part that will resolve this explicit bug. However, it does concern me overall. I've been trying hard to sell developers on the use of SCL. However, based on this cadence of maintenance releases it seems like that isn't something I should be doing. 2.7.5 is over 2 years old and If I remember correctly SCLs were supposed to only be on a 3y support cycle. I get that every release can't be provided and that there is a lot to releasing. But the opposite side is that without a more regular cadence advocates like myself have to question whether its a valid solution for our projects. And 2.7 might be on odd one cause its also the main branch of el7.. and they seem to be on similar releases. i dont know.
(In reply to Greg Swift from comment #2) > For the most part that will resolve this explicit bug. > > However, it does concern me overall. I've been trying hard to sell > developers on the use of SCL. However, based on this cadence of maintenance > releases it seems like that isn't something I should be doing. 2.7.5 is > over 2 years old and If I remember correctly SCLs were supposed to only be > on a 3y support cycle. > > I get that every release can't be provided and that there is a lot to > releasing. But the opposite side is that without a more regular cadence > advocates like myself have to question whether its a valid solution for our > projects. I think you're mixing two different things here. SCLs are a technology and RHSCL is a product. Just because one specific SCL on softwarecollections.org has certain version of Python (and is pretty much a free rebuild of an RHSCL collection), doesn't mean that SCLs in general are not suitable for certain use case. IOW: SCL as a technology shouldn't be blamed just because "python27" doesn't update according to your needs - I still believe that SCL is a very good technology for developers. I understand that everyone's needs are different and that the update cycle of python27 might not suit you. Please take into account that SCLs on softwarecollections.org are a freely available rebuild of RHSCL and as such they provide pretty much no guarantee if/when they'll get updated. I'm trying to keep the Python SCLs on softwarecollections.org in sync with RHSCL just because keeping things in sync makes a lot of things easier. Now, since RHSCL doesn't really have an upstream (you could rather say that *it is* upstream and CentOS/softwarecollections.org just have rebuilds), some changes to how RHSCL is being made have been proposed [1]. This proposal will effectively mean reversing the current state - softwarecollections.org should become a real upstream for RHSCL. That, among other things, means that SCLs on softwarecollections.org will be updated regardless of RHSCL - hopefully they'll get very close to your usecase (note, that this will still stay an unsupported community project, though, so no guarantees). This will probably still take some time, but should happen eventually. To sum it up, we see the problems with the current state and we're working on improving it. Still, if an SCL doesn't meet your requirements, you can just create a new SCL according to your needs. Hope this explains things better. > And 2.7 might be on odd one cause its also the main branch of el7.. and they > seem to be on similar releases. i dont know. [1] https://www.redhat.com/archives/sclorg/2015-February/msg00023.html
So, I completely think that SCL as a technology is a great concept, which is why I've spent its entire life encouraging admins and devs to use it. I also recognize the difference between SCL the technology (love it), a SCL the implemented collections (wavering in affection), and RHSCL the supported product (don't use for several reasons, not technology related). I'm glad to see that the concept of improving the flow for RHSCL/SCL is being worked on. However, I feel that your response was overly dismissive of a significant issue with the viability of softwarecollections.org as a resource. While I agree that needs can be very different, it seems that providing a public functional example that bit rots is not an effective way to gain and maintain mind share. If I deploy a product using a distributed and existing collection from scl.org and hit a bug which can be easily resolved with a patch released upstream, I shouldn't have to a) wait 2 years for the collection to refresh b) go recreate the collection myself. Using the 'provided as is with no guarantee' excuse to justify the lack of updates makes me wonder why the collection isn't set to just auto-update in the first place. If its 'no guarantee', why not at least ensure its getting security updates? Thank you for the response, I dont really expect this ticket to fix all the things, just raising a concern.
(In reply to Greg Swift from comment #4) > So, I completely think that SCL as a technology is a great concept, which is > why I've spent its entire life encouraging admins and devs to use it. I also > recognize the difference between SCL the technology (love it), a SCL the > implemented collections (wavering in affection), and RHSCL the supported > product (don't use for several reasons, not technology related). > > I'm glad to see that the concept of improving the flow for RHSCL/SCL is > being worked on. However, I feel that your response was overly dismissive of > a significant issue with the viability of softwarecollections.org as a > resource. Sorry about that, it was definitely not my intention to sound dismissive of this issue. > While I agree that needs can be very different, it seems that providing a > public functional example that bit rots is not an effective way to gain and > maintain mind share. Agreed. > If I deploy a product using a distributed and existing collection from > scl.org and hit a bug which can be easily resolved with a patch released > upstream, I shouldn't have to a) wait 2 years for the collection to refresh > b) go recreate the collection myself. Using the 'provided as is with no > guarantee' excuse to justify the lack of updates makes me wonder why the > collection isn't set to just auto-update in the first place. If its 'no > guarantee', why not at least ensure its getting security updates? > > Thank you for the response, I dont really expect this ticket to fix all the > things, just raising a concern. I understand. Please note that all of the work I've been doing concerning scl.org has been done under huge time strain and I totally understand your issue and agree that there's a problem with outdated packages. As I mentioned in comment 3, these issues will be fixed by the new approach (scl.org should become upstream for RHSCL). I'm CCing Honza Horak, who is mostly working on defining/discussing the new workflow. Honza, do you have any timeframe on when the new approach will become effective, hence solving this issue? Any other comments? Thanks.
thanks for the followup. I understand how time strain can be on a project, and do appreciate all the work that goes into this.
I too have similar frustrations to Greg. We've also been advocating the use of SCLs, and the slow release cycle (among other things) is pretty disappointing. That scl.org will become upstream for RHSCL is good news, that's been one of my gripes. Another gripe is the lack of build dependencies as a part of the RHSCL product -- for some of these things I can't even reproduce the build because the build artifacts aren't available (which is why, if I recall, CentOS has refused to build most the SCLs -- another gripe by the way, considering the close(r) ties between RH and Cent). As for Python, 2.7.9 does have some significant, backwards-incompatible security changes having to do with the various OpenSSL vulnerabilities over the past few years. For my use case in particular, I'm not able to use the current py 27 SCL because of those changes. In particular, the requests library breaks (or more accurately, urllib3 breaks) because it tries to establish an SSL context (which doesn't exist prior to 2.7.9), raising an InsecurePlatformWarning exception. One fix is to upgrade to Py 2.7.9. The other fix is to install the 'security' extras along with requests -- which requires later versions of a number of packages which are in RHEL, and some which aren't in RHEL at all. Right now, I can't decide which will be more annoying to do, build a custom requests[security] package (which has a lot of other dependencies I'll need to build and distribute) or attempt to backport all the FIPS and other RH patches from the 2.7.5 SCL to 2.7.9 and just ditch the vendor provided SCL altogether. Anyways, I don't mean to complain or pile on, I didn't realize there were so few resources put toward the SCL components. I do think the concept of SCLs is a really useful one, and many of our end users are taking advantage of them (including me!).
(In reply to Bohuslav "Slavek" Kabrda from comment #5) > I understand. Please note that all of the work I've been doing concerning > scl.org has been done under huge time strain and I totally understand your > issue and agree that there's a problem with outdated packages. As I > mentioned in comment 3, these issues will be fixed by the new approach > (scl.org should become upstream for RHSCL). I'm CCing Honza Horak, who is > mostly working on defining/discussing the new workflow. Honza, do you have > any timeframe on when the new approach will become effective, hence solving > this issue? Any other comments? Thanks. The initiative is actually about combination of scl.org and CentOS SIG group [1], which is now a way to deliver things above basic CentOS. The idea is that we'll have much more open development of SCL within this CentOS SIG, while we plan: * to rebuild RHSCL packages * to prepare future RHSCL packages and let them use before available in RHSCL * to offer additional packages that extend RHSCL collections The current status is far from my positive expectations months back, so I'd rather not set any timeframe now -- some changes simply take more than we would wish there. Now, we still wait for the tooling on centos side; with those done we'll be able to import the RHSCL sources we have available to git.centos.org and we will be able to start with rebuilding. We also plan to have all the collections built in centos available on scl.org. We held by-weekly meetings on Wednesday on #centos-devel @ freenode, so feel free to join and consult. [1] http://wiki.centos.org/SpecialInterestGroup/SCLo (In reply to Jon McKenzie from comment #7) > Another gripe is the lack of build > dependencies as a part of the RHSCL product -- for some of these things I > can't even reproduce the build because the build artifacts aren't available I know this was a problem before, but I thought all these issues were solved in RHSCL 1.2, so can I know more details about what is missing, please? (here or e-mail)
If the dependency issue has been fixed with 1.2, that's good news, I hadn't read that. It sounds like things are already on the right track now, it's just a matter of time and resources. Admittedly, we had sort of soured on SCLs after Cent decided not to pursue most of the 1.1 SCLs but these all sound like positive developments.
*** Bug 1329132 has been marked as a duplicate of this bug. ***
Python is now updated to version 2.7.13 on softwarecollections.org. I've updated the text as well to reflect it, and I'm closing this bug.