[CentOS-devel] Repository structures for SIG and variants in the future

Thu Jan 16 01:24:42 UTC 2014
Trevor Hemsley <trevor.hemsley at ntlworld.com>

On 13/01/14 19:05, Jim Perrin wrote:
> As part of opening up the possibilities for SIGs and Variants within the
> CentOS ecosystem, we need to give some thought to how repositories
> should be structured so that different can cooperate with each other.
>
>
> What we have discussed in the past, and what I'd like to propose to the
> -devel community, is that we adopt a page similar to the KDE framework.
> The way I envision this working is as follows:
>
>  - Tier 1 repositories: Adds packages only. These repos may not update
> or replace anything in the core distribution. (Example: EPEL)
>
>  - Tier 2 repositories: These repositories may provide provide packages
> that update or otherwise enhance packages in the base distribution, but
> otherwise maintain compatibility.  (Example IUS
>
>  - Tier 3 repositories: These repositories contain packages that
> conflict with software inside the core distribution. This would be
> Xen4CentOS for example, which replaces the kernel, and adds in xen
> functionality.
>
>
> Each tier may choose to rely on dependencies from repositories in the
> tier  above it, but not the other way around. For example, the tier 3
> Xen4 repository could choose to rely on packages from a tier1 like EPEL,
> or a tier2 like IUS. However a tier1 or tier2 could not rely on a tier3.
> A good real-world example of this would be rpmfusion's dependence on the
> EPEL repository.
>
>
> The other aspect of this that needs to be discussed is package
> duplication. For example, several of the proposed SIGs have some overlap
> in their packages. Would the preference here be that each SIG/Variant
> maintain their own version of the package, or should there be a common
> package set established? Both methods fit into the model described
> above, and both have pros/cons associated.
>
>
>
>
> What does the community think about this?

One other thing to think about in advance perhaps: what happens when one
of the packages involved in a SIG variant gets picked up by RHEL and
becomes Tech Preview or Supported in the distro? Does that SIG repo go
from tier 1 to tier 2 in the timespan it takes to read the RH Release
Notes? :-)

Trevor