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. 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