[scl.org] Python "latest" SCLo

Nick Coghlan ncoghlan at redhat.com
Tue Jul 11 08:44:30 UTC 2017

On Mon, Jul 3, 2017 at 3:47 PM, Nick Coghlan <ncoghlan at redhat.com> wrote:
> On Fri, Jun 30, 2017 at 1:24 AM, Davis, Daniel (NIH/NLM) [C]
> <daniel.davis at nih.gov> wrote:
>> I’ve been lurking on this list for a while, and I wanted to bring myself up
>> to date.   I noticed some talk of a community SCL for a “latest” Python,
>> which would be a non-patched pure build of Python that is kept up-to-date by
>> the community.   Where is that at?   Who is leading it?
> That would be me, but it stalled while I was working on some Python
> 3.7 changes. Happily though, I have some time to spend on
> bootstrapping the "rolling Python" SCL this week, so I'm going to
> start working through the list of tasks at
> https://wiki.centos.org/SpecialInterestGroup/SCLo#head-b408f06ad89fd3a67686f755eafac7ce310ee081
> (using the rh-python35 collection as a starting point)

So I finally started working on the technical aspects of this, and as
near as I can figure out, what I'll need to do is:

1. Create a new sclo-python metapackage, using
https://github.com/sclorg-distgit/rh-python35/tree/master as a
starting point
2. For now, just create a `sig-sclo7-sclo-python` branch (we can look
at an sclo6 branch once 7 is working)
3. Edit https://github.com/ncoghlan/sclo-python/tree/sig-sclo7-sclo-python
for the rh-python35 -> sclo-python name change
4. Start doing some test builds in COPR as per

In parallel with that:

4. Submit a buildsys request for an sclo-python tag that's similar to
the existing rh-python35 one (akin to
https://bugs.centos.org/view.php?id=9661 )
5. Figure out what, if anything, needs to be done in terms of adding
relevant branches to the other Python repos on
6. Actually start building real SCLs in the CentOS build system for
publication to softwarecollections.org


P.S. Additional next step: provide feedback to the Fedora Modularity
group on which aspects of this strike me as being the most annoyingly
tedious, and what could potentially be done to make
distro-submodule-based SCL definitions and updates less time consuming
than the current process based directly on RPMs and dist-git :)

Nick Coghlan
Red Hat Platform Engineering, Brisbane

More information about the SCLorg mailing list