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

Re: [scl.org] CentOS and softwarecollections.org

On 09/30/2015 08:05 PM, Honza Horak wrote:
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

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
* (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
* every collection provides a separate RPM with the repo file

From my PoV non of these is very important for end-user, but I accept Mirek had a different opinion. Any SCL users around that could provide feedback what is important on end-user side?

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.

The solution I think would solve this is let user to specify manually the following for every SCL entry on scl.org:
* instructions how to install/use the collections
* for every platform:
- which platform it is (fedora22, fedora23, centos6, centos7, ...)
- link to package with repository
- link to listing file
If everything is provided, then it will look as it does now, If some field is missing, then end-users may complain. But scl.org wouldn't care what values the admin of SCL entry provides.


[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.


SCLorg mailing list
SCLorg redhat com

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