[scl.org] CentOS and softwarecollections.org

[Honza Horak]

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

 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.

Honza

> [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
>
> _______________________________________________
> SCLorg mailing list
> SCLorg at redhat.com
> https://www.redhat.com/mailman/listinfo/sclorg