Software Collections SIG

SIG Status: Approved

Board Member Helping Bootstrap: JimPerrin

The Software Collections SIG will provide an upstream development area for various software collections and related tools. Developers can build on and extend existing SCLs, so they don't need to re-invent the wheel or take responsibility for packaging unnecessary dependencies.


Resource Requirements

Mailing lists and Communications

Work with the CentOS resources and any discussions around that will take place on the centos-devel mailing list. All work related to SCL, user interactions and upstream development will take place on the existing software collections mailing list.

The SIG is usually available also on irc at #centos-devel on

Sync-up meeting

SIG Membership

The SCLo SIG will have a steering committee and committers. The steering committee will initially consist of:

List of other members is available at

New committers and members may be added by the steering committee. Steering committee members may interface with the CentOS board via the bootstrapping board member.

Committer privileges, once earned, do not expire unless revoked by the steering committee.

Getting involved

Some tips for active contributors

Roadmap and initial actions

Task list

The following are things that are on the todo list:

Steps for adding a new collection


Requesting CBS tags and targets

If you want to create tags and targets for a new collection follow these steps:

CBS tag inheritance

Sometimes an SCL wants to use packages from another SCL (either for building or for running). The buildroots for particular SCL don't usually contain any other packages than packages from the same SCL, so we need to request specific tags inheritance (e.g. when MongoDB SCL needs Maven SCL for building some of the packages, MongoDB tags need to inherit packages from Maven SCL). To request tags inheritance, a maintainer is required to submit a request like this:

Building packages for SCLo

Currently there is still no dist-git repositories available for the SCLo packages, but we can build packages directly like this:

cbs add-pkg sclo7-rh-mariadb100-rh-candidate --owner=sclo rh-mariadb100-mariadb
cbs build sclo7-rh-mariadb100-rh-el7 rh-mariadb100-mariadb-10.0.18-1.el7.src.rpm 

Once build, the CI should run the sanity tests and then we may tag them to the -testing repository, like this:

cbs add-pkg sclo7-rh-mariadb100-rh-testing --owner=sclo rh-mariadb100-mariadb
cbs tag-build sclo7-rh-mariadb100-rh-testing rh-mariadb100-mariadb-10.0.18-1.el7 

Putting packages to the testing repository

There is a workflow, that grabs all packages tagged with -testing tag every few hours and make them available at the testing repository at

In order to happen that way, every collection must be added to the workflow, only for the first time, by creating a ticket like this: Then, users may install it by installing and enabling one of the the following repos:

yum-config-manager --enable centos-sclo-rh-testing
yum-config-manager --enable centos-sclo-sclo-testing 

Releasing the packages

When we want to release the packages, the process is similar as releasing in the testing repository, i.e. the following:

cbs add-pkg sclo7-rh-mariadb100-rh-release --owner=sclo rh-mariadb100-mariadb
cbs tag-build sclo7-rh-mariadb100-rh-release rh-mariadb100-mariadb-10.0.18-1.el7 

Inheritance between tags

By default, there is no inheritance between tags of different SCLs. If some SCL needs to use packages from other SCL, we must ask for setting an inheritance between tags (request on Buildsys at

Using EPEL packages for SCLo

This is exclusive for sclo- namespace, i.e. Software Collections not being rebases of RHSCL collections.

It is not possible to use EPEL packages directly for SCLo builds, since only CentOS packages are available in CBS. So, EPEL packages required need to be built in CBS. However, there are more variants how those packages can be built (proposal for now):

We want to avoid dependency hell which would be caused by conflicts of packages in SCLo with EPEL packages (different packages would depend on different versions of the same package).

1. convert EPEL package into SCL and include it in particular SCL

2. packaged as normal package

3. rename EPEL package in SCLo repo

4. mixed cases (e.g. renamed for EPEL 6 and normal package for EPEL 7)

Testing SCLo collections in CI

Each collection has a set of tests to check it meets the expected package lists, is installable and that basic functionality works. These are run automatically on the CentOS CI service against the candidate tags, i.e. newly built packages.

Tests can be run locally on or remotely against an EL6/7 host. Helpers are provided in the repository to set up virtual machines under KVM.

New collections should add files to sclo-ci-tests via a pull request (example), adding the collection to the lists, new package lists, tests and a Jenkins config file. Many of the tests and scripts are symlinked, particularly for multiple versions of the same interpreter or collection.

Once a collection is added, the Jenkins Job Builder script (jenkins/ should be executed to update the jobs in CI. See jenkins/README for more details.

The collection naming breakdown

Software collection's name is cohesive identification that was chosen by author and is not supposed to be broke down to separate parts.

However, since the naming usually follows some guidelines, there is an example of sclo-vagrant1 software collection:

A prefix in the collection name:
1) allows "others" (users in particular) to have a distinguishing name per their requirement
2) SCL authors have one "collection name" wherever the collection will appear
3) users (open source projects, paying, whatever) have one collection name to target irrelevant of platform
More on the prefix available at:

Further information

SpecialInterestGroup/SCLo (last edited 2016-12-13 20:42:32 by HonzaHorak)