On 02/04/2014 06:00 PM, Karanbir Singh wrote: > On 02/04/2014 04:02 PM, Jim Perrin wrote: >>> 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. > > maybe it needs puppet, which needs ruby which comes from a repo that > replaces the base os ruby. So while it can exist as a tier1 in this > model, its dep tree is going to cascade upto tier3, so might as well > make it a tier3 repo. > >> >> So the issue seems to be more with the dependency tiering requirement >> rather than the categorization of the tiers themselves. > > yes, we need stuff to go into the lower tiers that have the ability to > change packages, so that other repos can then rely on them ( or require > them optionally, eg: opennebula-node-xen ) > >> >>> 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? > > or we find a way to have repos contain content that overwrites others, > and use namespace overload or something other mechanism to allow it at > any tier. > Yum priority= fits so nicely here. Just saying. -- Ljubomir Ljubojevic (Love is in the Air) PL Computers Serbia, Europe StarOS, Mikrotik and CentOS/RHEL/Linux consultant