[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[scl.org] CentOS and softwarecollections.org

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]