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

Mon Jan 13 19:24:49 UTC 2014
Jim Perrin <jperrin at centos.org>

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