On 01/13/2014 01:14 PM, Sam Kottler wrote:
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.
This would not be permitted. A tier 2 could rely on a tier 1, but a tier 1 would not be allowed to rely on a tier 2. Apologies if I wasn't clear about that. I probably could have worded it better.
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.
I like this approach, but how would you propose resolving two SIGs with conflicting patch requirements?