Hi!
On 04/11/2017 10:24 AM, Nick Coghlan wrote:
I've been mulling this idea over for the past couple of weeks, and I'm
wondering if it might make sense to create a rolling "sclo-python3"
SCL, that's initially forked from
https://www.softwarecollections.org/en/scls/rhscl/rh-python35/, but
explicitly promises to rebase to new Python feature releases when they
come out.
So if people were happy to always run on the leading edge (even for
X.Y.0 releases), they could use "sclo-python3", but if they wanted to
stay on a particular X.Y release for a while, they would need to
switch to the downstream rh-pythonXY SCLs.
Remi, if I wanted to do that, where would I start?
https://github.com/sclorg-distgit is useful as a reference for
submitting changes to existing community SCLs, but it doesn't provide
any guidance on how to start a new one (and that info is also missing
from the wiki).
It would be great to have a state-of-the-art Python in Enterprise Linux,
but I think it would be better using the existing (though lacking
maintenance) Python 3 in EPEL [0] mechanism.
While installing and using SCLs isn't hard, I think an RPM packaged
version is still easier for both maintenance and usage and people can
have EPEL packages built against it as well. In addition the transition
mechanism is smoother, as two Python versions are coexisting during the
transition period, whereas the rolling SCL would just switch and
everyone would have to immediately adjust.
What would be the advantage of creating a rolling 'scl-python3'
collection over the EPEL mechanism [1]?
[0] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3
[1] https://admin.fedoraproject.org/pkgdb/package/rpms/python34/
All the best,
Tomas
_______________________________________________
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg
