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