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

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.

>
>