On 01/13/2014 08:24 PM, Jim Perrin wrote: > 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. I see, so packages can only rely on packages that fall below their tier. > >> >>> >>> >>> 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? Generally it seems like the 'work upstream to fix it' approach would work in this case, too. As for patches that are mutually exclusive I don't have any real insight; I'm sure others have approaches that work well to solve the problem, though. That being said I think it's actually fairly rare for two patches to be mutually exclusive in tier 1 or 2. Maybe tier 3 should have a different policy around duplication across SIG's than the lower two? This seems natural anyhow since the reason tier 3 packages would generally exist is that there's something about them that make particularly different from the mainstream version. > >