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

[Jim Perrin]

On 02/02/2014 05:06 PM, Karanbir Singh wrote:
> Hi,
> 
> On 01/13/2014 07:05 PM, Jim Perrin wrote:
>>  - 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.
> 
> at fosdem we've tried to flesh out how this might work with some real
> world examples, and unfortunately this model might hit a few issues.
> 
> The actual structure and layers needs to be much simpler with dependancy
> allowed as you mentioned ( ie. tier 1 can only rely on itself and OS,
> tier2 can rely on itseld + one or more tier1's + os, tier3 can rely on
> itself + one or more tier2's, one or more tier1's and os ).


> Look at it this way, putting glusterfs, ceph in tier3 ( bcause they need
> a  modified build for qemu ) will mean that the only way openstack is
> able to consume it will be if openstack is in the same repo ( and they
> are all collected at a teir3 ), then cascade down and the entire dep
> tree needs to move back upto a teir3, at which point its all just a flat
> OS tree and tier3 repos.

But openshift would be able to exist as a tier 1 or tier2, since it's
simply adding packages without updating core distro rpms. So it depends
a bit on what the user wants to do.

> So with that in mind, i think repo's should be allowed to exist at any
> tier, with a repo being able to decide for itself if it wants to include
> content that replaces functionality + adds, or just adds. ie. adopt the
> Extras/ and Plus/ seperation ( with Plus/ automatically -required- to
> include Extras/ ) at each tier.


So the issue seems to be more with the dependency tiering requirement
rather than the categorization of the tiers themselves.

> nutshell: libvirt, qemu, xen4centos, ceph and friends are all going to
> be -required- to be tier1's and be allowed to replace ( namespace
> overload ?) components, so that every other component above in other
> teri1's or 2's or 3's are able to consume it.


They can't be tier1's if they're updating or conflicting with existing
packages, but we can certainly relax the dependency requirements to
resolve this. That should resolve this issue, right?


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