[scl.org] Workflow for Software Collections (SCLs) in CentOS

Honza Horak hhorak at redhat.com
Mon Feb 23 17:44:22 UTC 2015

This proposal considers the following:
  * we want to provide stable SCLs rebuilt from RHSCL for CentOS users
  * we want to have a platform for upstream development for collections 
    - will be part of the future RHSCL (same SCL name as in RHSCL uses, 
RH developers own those, others may contribute -- send patches)
    - have been part of RHSCL but will get some update eventually, so we 
want to test the fixes before applying in RHSCL
    - are not intended for RHSCL (those won't use "rh-" prefix [2], but 
should have some other prefix)

Some technical details of CentOS Build Service (CBS) at [3]
There are several projects in centos distgit (http://git.centos.org), 
those two are important for SCL:
  * sclo -- code of testing packages, uses fedora layout (specfile and 
sources directly in the repository, no directories), building rpms in 
CBS only from srpm, final rpms are testing only (tagged into sclX-testing)
  * rpms -- code of stable packages, centos layout (specfile and sources 
in SPECS, SOURCES directories), building rpms in CBS either from srpm or 
from scm, possible to build official rpms (tagged into sclX-release, 
request signing and releasing)

There are two koji tags set for all collections for every elX version (X 
is 6, 7, ...el6, el7, ...):
  * sclX-testing: default tag where all built srpms are tagged into
  * sclX-release: only rpms built from scm can be tagged here (and will 
be signed)

Workflow schema:

     git.c.o       CBS         scl.org [1]
   develop in
  sclo project
       |  \
       |   \
       |     build from srpm
       |     for testing only
       |            |
       |            |
       |     rpm tagged into
       |      sclX-testing
       |                   \
       |                    \
       |                    available in
       |                    sclo-testing
       |                        repo
  import srpm
   into rpms
              build release
                from scm
               tagged into
                             available in
                 tag into
              sign & release
                             available in

Description of the scheme above
Workflow during development phase:
  * this part is valid for future RHSCL collections that (both net new 
and major update) are not yet available in RHSCL
  * contributors prepare new collection under sclo project
  * contributors build testing rpms from srpm
  * rpms are tagged into sclX-testing
  * scl.org [1] imports specific collections from sclX-testing

Workflow during maintainance phase:
  * this part is valid for collections that are/were released
  * contributors prepare patches under sclo project to test them before 
applying (in RHSCL or non-RH stable SCL) -- fix smaller bugs, extend 
stable collection in compatible mode, generally maintain compatibility 
of the collection
  * contributors build testing rpms from srpm
  * rpms are tagged into sclX-testing
  * srpms are manually imported from sclo to rpms project @ git.c.o
  * contributors build official packages from scm and tag them into 
  * contributors ask for signing and publishing
  * scl.org imports specific collections from sclX-release and 
potentially also from sclX-testing

Specific for RH collections:
srpm can be automatically imported to rpms project or even to sclo 
project on errata publishing if maintainer wishes so

Some open questions
Q: scl.org to provide a separate repository for each collection? or one 
repository for all collections in -testing?
Proposal: we can start with one common repository for all stable centos 
collections, the same we do in RHSCL?

Q: what about centos vs epel?
Proposal: if there are some packages that want to use centos collections 
in the future, epel should start to build above centos' sclo repos. That 
means the same collections don't need to be build again in epel. How is 
it done in other centos SIGs in case they provide the same components in 

[1] https://www.softwarecollections.org/en/scls/
[2] https://www.redhat.com/archives/sclorg/2015-February/msg00022.html
[3] http://cbs.centos.org


More information about the SCLorg mailing list