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

[Jim Perrin]

On 01/15/2014 01:28 AM, Ned Slider wrote:
> On 13/01/14 19:05, 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.
>>
>>
>> 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.
>>
>>
>>
>>
>> What does the community think about this?
>>
>>
>>
>>
> 
> I'm in favour of any process that makes the use of 3rd party 
> repositories more compatible.
> 
> Some things to think about:
> 
> How would one handle repositories that fall into multiple categories 
> above. For example, Repoforge main repo channel would be tier 1 (.rf 
> packages) whereas packages from their extras channel (.rfx) would be 
> tier 2. Likewise, elrepo has a main tier 1 channel, a tier 2 extras 
> channel and a kernel channel which might be tier 3.


This is primarily for SIG and Variant repos, since we can't control what
3rd parties do.  It would be rather nice to get everyone working in the
same direction. As you said, repoforge and elrepo already mostly line up
with this.



> How would one handle conflicts and incompatibilities between multiple 
> tier 1 repositories (e.g, Repoforge and EPEL)?

Ljubomir and Manuel were discussing the required use of include/exclude
statements for repository structures, but I'm not sold on that idea yet.

Since this would be for sig/variant use, and in git.centos.org we should
be able to reduce the level of duplication and have groups working
together.

Apart from that, I think it would best be left to the SIGs to document
their requirements and educate their users about any potential for overlap.

> Of course these aren't new issues and one can easily write a very long list.
> 
> As much as I hate the idea of killing off independent 3rd party 
> competition, I'm minded to think the only sane way to handle this is to 
> have one centralised Enterprise Linux repository, quite possibly 
> segregated into 3 tiers as you outline above. As exemplified by the 
> current situation, it's never going to be completely practical having 
> multiple builds of Package A built against different versions of 
> Packages X, Y and Z all floating around in different 3rd party community 
> repositories.


Agreed. This is a systemic failing that's been around for years. My goal
here is simply to provide some basic structure and resources (git, build
system, mirror network, and easier deployment within the distro) to the
individuals or groups who want to participate. The structure we're
outlining is mostly common sense, and is mostly in use already. That
should hopefully help smooth the transition for people wishing to
participate.


> Whether anyone (or any group) is able to demonstrate the leadership 
> necessary to bring everyone together under one umbrella and resolve all 
> the issues is another question.


We'll never be able to make everyone happy or resolve all the issues. If
we're able to provide something that works well for the majority of end
users and makes project life easier for the builders/developers, I'll
consider that a win.




-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77