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

Karanbir Singh mail-lists at karan.org
Tue Feb 4 17:00:24 UTC 2014


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.

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



More information about the CentOS-devel mailing list