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

Sun Feb 2 23:06:43 UTC 2014
Karanbir Singh <mail-lists at karan.org>


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.

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.

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.

- KB

Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc