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

Mon Jan 13 19:14:36 UTC 2014
Sam Kottler <s at shk.io>

On 01/13/2014 08:05 PM, 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.

What about a tier 1 relying upon a tier 2? It seems like there could be 
some ABI issues in allowing that unless I'm missing some detail.

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

IMO the SIG's should both use the same package and both groups could 
help maintain it. Obviously there will likely be situations where one 
SIG needs a certain version and the other needs a different one; seems 
like a situation where SIG's should work upstream to unify versions. As 
for whether that's a viable approach (re: upstream coordination) will 
probably only be told with time.

> What does the community think about this?