On 09/14/2011 06:59 AM, James A. Peltier wrote: > Yes, I did notice that, just wondered why. It seems more prone to breakage (creating multiple symlinks vs one) There are a couple of reasons. I wont go into all, but the 2 that stick out the most for me are: 1) symlinking a step deeper means we can have more finer grained control over the content exported from the <release>/ and the <release>/<repo> level, specially when it involved shared content ( Extras as one functional example, addons and contribs as another - but non impacted here ) 2) This is the more important one : with /6/ and 6.X/ being real physical locations there is still the door open that allows /6/ to become the CR repo. Entirely, across the OS/ and Updates/+ CR/ whereas 6.X/cr/ then becomes local to what is representative of a next-release content repo ( in relation to the point release its injected into ). This becomes even more relevant when you factor in 'CR/ content will not move to vault.c.o when the <release>.X content does'. Furthermore, this is an important issue when we consider that the CR repo is opt-in, having a /6/ stream that is always updated and always just-usable irrespective of what 6.X one installs on their machines is always going to be a good goal to achieve, imho. Impact on how we do things, how we store stuff, stage content, get it into the mirrors, export to users and yum clients : massive. Ofcourse, the only experience that needs to be protected is the yum-client interface, and can we achieve this refactor without impacting yum-client interfaces ? I dont know. What I do know, is that very very few external mirrors have the capacity to handle something of this nature. Solve'able problems no doubt. There are also site-specific benefits like being able to add and track local repo's without needing to add in hackery over the centos mirror rsync exported content within a <release>/ or <release>.X/ tree. And for people who run multiple machines, or need to have different production environments this tends to be quite a big deal. >From the user perspective, it should not make a difference as to where the symlinks are setup to -> from. If there is an impact, do tell. - KB