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