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? -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77