[scl.org] CentOS and softwarecollections.org

[Honza Horak]

We touched the topic of how to connect CentOS builds with scl.org today 
on the SCLo meeting after we talked about it f2f with Mirek and Jakub 
earlier today (I found few things are different than I expected [1], 
which is reason why re-opening this topic). Let's try to agree on some 
solution.

The purpose why scl.org should advertise CentOS builds is that scl.org 
is meant to be the gate to get any SCL packages for end users. Also, the 
copr builds won't be maintained as soon as SCLo builds are released.

There these two issues I'd like to narrow down:

Issue #1: the scl.org pulls packages from copr and keeps a copy of them 
on scl.org. The reasons for this seem to be:
* limited network abilities of copr
* being able to test packages before advertising them on 
softwarecollectoins.org
* (anything else?)
In CentOS the network is sufficient and there is also a process that 
allows to test packages before releasing. So, pulling packages from 
CentOS doesn't seem to be necessary.

Issue #2: there are two ways how end-users may get the repositories for 
SCLs enabled:
A) enable all collections at once (actually there will be two 
repositories in CentOS -- one for RHSCL collections and another one for 
the rest, which is supposed to work more like EPEL)
B) enable repository for every collection separately (how scl.org work 
with copr now)

The differences from my PoV:

Variant (A) depends on YUM to install all the dependencies, while (B) 
allows users not to spoil YUM space with unwanted packages (which might 
be issue when collections conflict on RPM metadata level for example, 
but requires manually enable all depended collections).

There is also a list of related collections generated automatically on 
scl.org (see example for httpd at 
https://www.softwarecollections.org/en/scls/rhscl/httpd24/) which imho 
might be done in both cases.

Variant (A) doesn't support some use cases that (B) does now:
* listing rpms for the specified collection only
* having install/usage instructions generated automatically for all 
collections
* every collection provides a separate RPM with the repo file

On the other hand, if we go with (A), we don't have to pull the 
packages, because the common repositories will be created already on 
CentOS side.

[1] The thing that is different than I expected, is that the packages 
from CBS repository (e.g. 
http://cbs.centos.org/repos/sclo6-rh-mongodb26-rh-release/), once they 
are released (which means singing and putting into the final repo), 
won't get back to the repo above again. So packages from there can't be 
used for scl.org. Another new finding is that pulling packages doesn't 
seem to be necessary for CentOS.

Cheers,
Honza